From: tig...@sco.COM (Tigran Aivazian)
Subject: Linux, UDI and SCO.
Date: 1998/09/18
Message-ID: <Pine.LNX.4.02.9809180946480.8400-100000@einstein.london.sco.com>
X-Deja-AN: 392356073
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
Hello guys,
The stuff below is no longer a secret so I think I can share it with you.
It does mention Linux quite a few times and may even answer someone's question
as to whether SCO is interested at all in Linux.
Regards,
------ -------- --------- -------- -- - -- ---- --
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | Email: tig...@sco.com
SCO TEAMS WITH INTEL TO ACCELERATE UNIX SYSTEM GROWTH AND ADOPTION
Companies Use Uniform Driver Interface to Deliver Common Device Support
Across Multiple UNIX Operating Systems
INTEL DEVELOPER FORUM, Palm Springs, CA (September 16, 1998) - In a move
aimed at accelerating the growth of UNIX systems on Intel processor-based
servers, SCO (NASDAQ:SCOC) today announced its support of Intel
Corporation's adoption of the Uniform Driver Interface (UDI) as a standard
device interface. In addition, Intel will work with SCO and Project UDI, to
port UDI to the Linux operating system and distribute as freeware.
UDI allows device drivers to be portable across both hardware platforms and
operating systems without any changes to the driver source. This
significantly lowers the cost of driver development, speeds time-to-market
of new devices, and allows manufacturers to allocate development resource
on improving device performance, features and functionality. SCO held the
first public demonstration of this technology at SCO Forum98 last month,
running the same driver under the SCO OpenServer, SCO UnixWare 2, UnixWare
7, and the Hewlett-Packard HP-UX operating systems.
UDI is a specification backed by multiple UNIX system providers, including
Compaq, HP, IBM, NCR, SCO, and Sun Microsystems, as well as leading
companies such as Adaptec, Interphase Corporation and Lockheed Martin. SCO
was instrumental in proving the UDI concept and driving the formation of a
multi-company, joint development effort to produce a prototype UDI
environment implementation and sample drivers. This project, based on core
code provided by SCO, resulted in working UDI implementations on seven
different operating systems.
"Standardization in this industry is what drives up the performance and
innovation curves," said Ray Anderson, SCO's senior vice president,
Marketing. "Intel's support of UDI as a standard means that all UNIX OS
vendors can use a common device driver on all Intel platforms. SCO and
Intel will strongly support the movement to standardize the use of UDI for
all UNIX platforms on Intel, which we believe will generate even more
momentum for the already exploding UNIX on Intel market."
"Accelerating the deployment of UNIX on Intel-based servers is an important
element in the growth of the standard high volume server model and in
bringing price/performance advantages to the reliable, available and
scalable benefits of UNIX," said John Miner, Intel vice president and
general manager, Enterprise Server Group. "SCO and Project UDI have already
made a great deal of progress in defining a common framework and Intel is
doing its part to deliver it to the industry."
Cost savings is among the many benefits of UDI by reducing a company's time
and resources in developing and testing of drivers. Independent research
firm, International Data Corporation (IDC), recognizes this as a
substantial benefit for developers and end-users.
"Having a standard device driver infrastructure may result in significant
savings to end-user organizations and developers alike," said Dan
Kusnetzky, program director for International Data Corporation's operating
environments and serverware programs. "If an end-user organization could
reduce the staffing required to install and maintain its server software by
only one person, that could result in a three quarter of a million dollars
savings over five years. If a developer was able to support a broad number
of systems with less system testing and fewer engineers doing testing, the
savings could stack up to be even more."
UDI for Open Source Community
SCO strongly supports the growth of standards-based computing and
encouragement of open systems development. SCO, with Intel and Project UDI,
will support the open source community by working to ensure that UDI works
on the Linux operating system.
Anderson continued, "The Linux and open source movements are powerful
forces in the industry that are creating a huge resurgence in the interest
in the UNIX System. It helps to bring the community together again and with
UDI available on the Linux system, their developers can use the latest UNIX
devices and peripherals on the market."
About UDI
UDI isolates drivers from operating system policies, as well as platform
and I/O bus dependencies. This allows driver development to be totally
independent of OS development. In addition, the UDI architecture insulates
drivers from platform specifics such as byte-ordering, DMA implications,
multi-processing, interrupt implementations and I/O bus topologies. More
information on Project UDI is available at http://www.sco.com/UDI
About SCO
SCO is the world's number one provider of UNIX server operating systems,
and the leading provider of network computing software that enables clients
of all kinds - including, PCs, graphical terminals, NCs, and other devices
- to have Webtop access to business-critical applications running on
servers of all kinds. SCO designed Tarantella software, the world's first
application broker for network computing. SCO sells and supports its
products through a worldwide network of distributors, resellers, systems
integrators, and OEMs. For more information, see SCO's WWW home page at:
http://www.sco.com .
# # #
SCO, The Santa Cruz Operation, the SCO logo, SCO OpenServer, Tarantella,
the Tarantella logo, and UnixWare are trademarks or registered trademarks
of The Santa Cruz Operation, Inc. in the US and other countries. UNIX is a
registered trademark of The Open Group in the US and other countries. All
other brand and product names are or may be trademarks of, and are used to
identify products or services of, their respective owners.
___________________
Brian Ziel
Manager, Product PR
Tel: 831-427-7252
Fax: 831-427-5418
Email: mailto:bri...@sco.com
Press: http://www.sco.com/press
___________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/18
Message-ID: <m0zJzQk-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 392383086
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.4.02.9809180946480.8400-100000@einstein.london.sco.com>
Newsgroups: muc.lists.linux-kernel
> SCO strongly supports the growth of standards-based computing and
Oh good, then as one of the major founder members of the I2O cabal does that
mean they'll be trying to get I2O made open ?
> encouragement of open systems development. SCO, with Intel and Project UDI,
> will support the open source community by working to ensure that UDI works
> on the Linux operating system.
"We'd like to fill your truely free OS with binary drivers and ruin things"
is at least one take on the potential _effect_ of such things regardless of
good intentions that may exist. Now there are easy ways to counteract that
one is to ensure the code that Linux UDI modules are _linked_ with is
all GPL.
> Anderson continued, "The Linux and open source movements are powerful
> forces in the industry that are creating a huge resurgence in the interest
"Help help we're being overrun" ;)
UDI does actually seem to have some technical problems with Linux paticularly
on the infrastructure side. It's visibly designed for things that are at
least common in their core interfaces (ie they run a V7 derived unix core
with BSD nailed on streams or similar networking stack)
The networking one shows up elsewhere - At one point I was trying to build
an NDIS5 layer for Linux but NDIS has the 'multiple buffers per packet'
religion built into it, even though the rest of it is credibly portable.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: nath...@chirp.com.au (Nathan Hand)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/18
Message-ID: <Pine.LNX.4.00.9809182237500.5743-100000@stoli.spirits.org.au>#1/1
X-Deja-AN: 392396218
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0zJzQk-000aQwC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
On Fri, 18 Sep 1998, Alan Cox wrote:
> > encouragement of open systems development. SCO, with Intel and Project UDI,
> > will support the open source community by working to ensure that UDI works
> > on the Linux operating system.
>
> "We'd like to fill your truely free OS with binary drivers and ruin things"
> is at least one take on the potential _effect_ of such things regardless of
> good intentions that may exist.
The other obvious reason that SCO wants UDI to succeed is that Linux
has tonnes of drivers and SCO does not, and SCO wants to invent some
plausible way of leeching off the Linux drivers.
Of course, I am just being argumentative, because I actually support
UDI, because it will let me install Solaris on more hardware, and it
will help UNIX in general (even if not specifically Linux).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: pa...@atrey.karlin.mff.cuni.cz (Pavel Machek)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/18
Message-ID: <19980918170357.64551@atrey.karlin.mff.cuni.cz>#1/1
X-Deja-AN: 392451059
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0zJzQk-000aQwC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
Hi!
> The other obvious reason that SCO wants UDI to succeed is that Linux
> has tonnes of drivers and SCO does not, and SCO wants to invent some
> plausible way of leeching off the Linux drivers.
Even with UDI, SCO can not use Linux drivers: linux drivers _have to_
be GPL in order to link with kernel. And unless SCO is going GPL, they
can not link with GPL code... (Unless they find way to insert GPL code
as a module - that might be legal.)
Pavel
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: tig...@sco.COM (Tigran Aivazian)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/18
Message-ID: <Pine.LNX.4.02.9809181515460.1012-100000@einstein.london.sco.com>#1/1
X-Deja-AN: 392457403
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0zJzQk-000aQwC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
Alan,
I can't argue with you because I mostly agree with your opinion.
My only point was "if there is something useful in this - take it. otherwise
- ignore it" - very simple and pragmatical :) (e.g. in order to make use of
Olicom's token ring cards at home I used the binary (non-GPL) driver. I didn't
care (in that context, not generally!) whether it was GPL or not as long as it
worked and there was nothing GPL'ed that would replace it).
So, if introduction of UDI gives hardware vendors an excuse to justify
not-releasing the specs that is very bad. But it is better than having neither
excuses, nor specs, nor UDI (non-GPL) binary drivers...
Regards,
------ -------- --------- -------- -- - -- ---- --
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | Email: tig...@sco.com
On Fri, 18 Sep 1998, Alan Cox wrote:
> > SCO strongly supports the growth of standards-based computing and
>
> Oh good, then as one of the major founder members of the I2O cabal does that
> mean they'll be trying to get I2O made open ?
>
> > encouragement of open systems development. SCO, with Intel and Project UDI,
> > will support the open source community by working to ensure that UDI works
> > on the Linux operating system.
>
> "We'd like to fill your truely free OS with binary drivers and ruin things"
> is at least one take on the potential _effect_ of such things regardless of
> good intentions that may exist. Now there are easy ways to counteract that
> one is to ensure the code that Linux UDI modules are _linked_ with is
> all GPL.
>
> > Anderson continued, "The Linux and open source movements are powerful
> > forces in the industry that are creating a huge resurgence in the interest
>
> "Help help we're being overrun" ;)
>
> UDI does actually seem to have some technical problems with Linux paticularly
> on the infrastructure side. It's visibly designed for things that are at
> least common in their core interfaces (ie they run a V7 derived unix core
> with BSD nailed on streams or similar networking stack)
>
> The networking one shows up elsewhere - At one point I was trying to build
> an NDIS5 layer for Linux but NDIS has the 'multiple buffers per packet'
> religion built into it, even though the rest of it is credibly portable.
>
> Alan
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: terr...@tbcnet.com (Terry L Ridder)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/18
Message-ID: <36028895.339C1503@tbcnet.com>#1/1
X-Deja-AN: 392480660
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980918104155.560B-100000@lo-pc3035a>
Organization: Blue Danube Software
Newsgroups: muc.lists.linux-kernel
Hello;
There are basically only two ways this UDI scenario can work.
1. All the commercial backers of it, switch to using Linux for their OS
and they just build hardware, or in SCO's case additional software
add-ons.
2. SCO releases all UNIX source code under the GNU GPL, HP releases all
sources code of HP-UX, Sun releases all source code for SunOS and
Solaris.
You might as well ask Apple to release all the source code to
NextStep/OpenStep/
Rhapsody.
Personally I would prefer the first choice.
A more radical move would be for SCO to:
1. Give, with no strings attached, the UNIX source code to FSF aka RMS.
2. Give, with no strings attached, the UNIX source code to Linux
International.
Any of the above scenarios would surely have major impacts on Microsoft,
and Bill Gates.
Alex Buell wrote:
>
> On Fri, 18 Sep 1998, David Luyer wrote:
>
> > They want to help us code something, or code it for us. They offer us
> > some hope for drivers released at the same time as new hardware in return.
> > This sounds mostly good to me. The main negative is that UDI may cause some
> > places to not release hardware specs, since we can use the UDI driver, and
> > the "I can't use it on Linux" argument wouldn't hold anymore. Then we may
> > be stuck with potentially slow, inefficient drivers. And of course the
> > threat of a proliferation of binary-only drivers, which is bad in the whole
> > GPL ideology and bad in that it's unknown code, possibly buggy, no chance
> > to review it, etc.
>
> To be honest, this UDI initative is scary. For this to work, they MUST
> allow fully GPL'd sources. Or they can go stick it where the sun doesn't
> shine. Reading the original post seemed to indicate that the major corps
> behind this initiative would have full control. That worries me because I
> can think of no better backdoor like this for them to delibrately write
> crippled drivers for Linux in order to de-rail the whole process and make
> BillyShit Gates happy.
>
> Cheers,
> Alex.
>
--
Terry L. Ridder
Blue Danube Software (Blaue Donau Software)
"We do not write software, we compose it."
When the toast is burnt
and all the milk has turned
and Captain Crunch is waving farewell
when the Big One finds you
may this song remind you that they
don't serve breakfast in hell
==Breakfast==Newsboys
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: ander...@inconnect.com (Erik Andersen)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/18
Message-ID: <Pine.GSO.4.02A.9809181047580.2269-100000@ultra1>#1/1
X-Deja-AN: 392498433
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <19980918170357.64551@atrey.karlin.mff.cuni.cz>
Newsgroups: muc.lists.linux-kernel
On Fri, 18 Sep 1998, Pavel Machek wrote:
> Hi!
>
> > The other obvious reason that SCO wants UDI to succeed is that Linux
> > has tonnes of drivers and SCO does not, and SCO wants to invent some
> > plausible way of leeching off the Linux drivers.
>
> Even with UDI, SCO can not use Linux drivers: linux drivers _have to_
> be GPL in order to link with kernel. And unless SCO is going GPL, they
> can not link with GPL code... (Unless they find way to insert GPL code
> as a module - that might be legal.)
>
> Pavel
Two issues though:
1) Why can't BSD, NPL, Artistic, and other free code be linked
with the kernel? As I read the GPL, this isn't a problem, and
unless I am mistaken, there are a number of linux drivers that have
made use of *BSD code, which is not GPL. I think you are mistaken
in your statement.
2) It is reasonable to consider a device driver running under a UDI layer
as an "independent and separate works in themselves", and in that context,
there is no problem using it under a non-free OS. It is just a program
that runs on the OS (in kernel space), and as such it is no different
then running gcc under SCO or solaris, etc. Not a problem, as long as
they also distribute (or point to) the source.
Remember, "mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License." If we write it, they can ship it -- but it
will be free, and can be fixed.
I say we have everything to gain by supporting this, and little to lose.
We get binary only drivers for unsupported devices, and then when we get a
free driver that is better written, everyone will use it because of the
inherent advantages of a free driver.
At least that is how I read things. TRMV (Your Reading May Vary),
-Erik
--
Erik B. Andersen Web: http://www.inconnect.com/~andersen/
email: ander...@debian.org
--This message was written using 73% post-consumer electrons--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: alex.bu...@tahallah.demon.co.uk (Alex Buell)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/18
Message-ID: <Pine.LNX.3.96.980918132620.223B-100000@lo-pc3035a>#1/1
X-Deja-AN: 392564795
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <36028895.339C1503@tbcnet.com>
Newsgroups: muc.lists.linux-kernel
On Fri, 18 Sep 1998, Terry L Ridder wrote:
> 1. Give, with no strings attached, the UNIX source code to FSF aka RMS.
> 2. Give, with no strings attached, the UNIX source code to Linux
> International.
>
> Any of the above scenarios would surely have major impacts on Microsoft,
> and Bill Gates.
You've forgotten that Micro$haft owns SCO. I believe this is what Bill
Gates is really up to; trying to tie us up with useless UDI junk and and
benefit from it at our expense.
So, personally, it's thumbs down on this one. Why don't *we* counter with
our own GPL'd unified driver interface? That will put the kibosh on them;
especially if we can persuade some smaller commerical players to
participate, and ignore the SCO/UDI initiative. They will have no choice
but to follow us - we can use the same tactics Microsoft used with DR-DOS.
That is, force an Oops if faced with a UDI/SCO aka MS driver. That'll
teach the bastards to screw with us like what they did to DR-DOS with
MSDOS/Windows 3.1. Ain't nothing like a taste of cold nasty medicine..
Sheesh, I'd better put on the flame proof trousers (I know there's
someone from SCO in here)
Cheers,
Alex.
---
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
Check out http://www.tahallah.demon.co.uk
Linux lo-pc3035a 2.1.120 #24 Tue Sep 8 09:08:48 EDT 1998 i586 unknown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/18
Message-ID: <m0zK6pC-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 392570229
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.GSO.4.02A.9809181047580.2269-100000@ultra1>
Newsgroups: muc.lists.linux-kernel
> Two issues though:
> 1) Why can't BSD, NPL, Artistic, and other free code be linked
> with the kernel? As I read the GPL, this isn't a problem, and
Traditional BSD license code isnt free. The GPL has a single magic clause
in it which includes the words "no additional restrictions". That clashes
with the BSD advertising clause. The BSD clause without advertising doesnt
clash
> Remember, "mere aggregation of another work not based on the Program
> with the Program (or with a work based on the Program) on a volume of
> a storage or distribution medium does not bring the other work under
> the scope of this License." If we write it, they can ship it -- but it
> will be free, and can be fixed.
On the contrary. It depends on the kernel. It wont read a disk without it.
It is clearly linked. The kernel license has a specific set of additional
permissions on licenses so unless the UDI framework linked to the module is GPL
the problem [does/doesnt - to your viewpoint] arise.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/18
Message-ID: <m0zK7FT-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 392575527
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980918132620.223B-100000@lo-pc3035a>
Newsgroups: muc.lists.linux-kernel
> You've forgotten that Micro$haft owns SCO. I believe this is what Bill
A small percentage. SCO and Microsoft's last public meeting was the
European competition people - and one of them on each side of the argument
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: terr...@tbcnet.com (Terry L Ridder)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/19
Message-ID: <36033428.64EC604@tbcnet.com>
X-Deja-AN: 393505809
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980918104155.560B-100000@lo-pc3035a>
Organization: Blue Danube Software
Newsgroups: muc.lists.linux-kernel
Hello;
For background on my comments I would suggest reading the original
reports at:
IT Week: Intel looks to Linux community for help with UDI
http://www.zdnet.co.uk/news/1998/37/ns-5501.html
A Brief Quote from the above article is below
<Begin Quote>
"The advantage of releasing to the Linux community is that their
work will give Unix OS vendors a basis to work from," Quick added,
though he stressed that the specification will still be tightly
controlled and standards based.
<End Quote>
Uniform Driver Interface (UDI)
http://www.sco.com/udi/
Below is a brief quote from the above Web Page:
<Begin Quote>
To demonstrate the feasibility of the UDI architecture and to gain
real-life experience before finalizing the specification, a prototype
environment implementation was created and ported to the following
platforms,
running a SCSI driver from Adaptec and/or a network interface
driver from Interphase.
Operating System Processor Type
Compaq Digital UNIX Alpha (64-bit)
Hewlett-Packard HP-UX PA-RISC
IBM AIX PowerPC
NCR MP-RAS IA-32 (x86)
SCO OpenServer 5.0.5 IA-32 (x86)
SCO UnixWare 2.1.3 IA-32 (x86)
SCO UnixWare 7 IA-32
(x86)
Sun Microsystems Solaris Sparc
<End Quote>
Last but not least read the GNU General Public License at:
GNU General Public License
http://www.fsf.org/copyleft/gpl.html
Notice that the first URL which I quoted clearly indicates that
the commercial vendors would use the Linux UDI drivers as a basis
to work from. This is very clearly stated by Quick.
Background on Mr. Quick:
Kevin Quick, chairman of Project UDI.
Kevin Quick's e-mail address is kqu...@iphase.com
Now notice the proof of concept quote from the Project UDI home page:
Listed here are Digital UNIX, HP-UX, Solaris, AIX, UnixWare 2.1.3,
UnixWare 7, and OpenServer 5.0.5.
Hardware platforms lists are Alpha, PA-RISC, PowerPC, Intel, and Sparc.
Linux runs on all the above mentioned platforms.
Assume for the moment that the Linux Community does write Linux UDI
device
drivers. Let us assume for the moment that all peripheral vendors will
release
all needed/wanted/required documentation for their peripherals to the
Linux
Community. It would be the option of the UDI device driver author to
release
the driver under alternate software licenses in addition to the GNU
General
Public License. This would not present a problem for the commercial OS
vendors
nor for the peripheral vendors, they would just use the alternate
software
license. However, if the author only releases the UDI device driver
under
the GNU GPL the commercial OS vendors could not use that driver in
their own closed source OS. The only way they could use it was if their
source code was released under the GNU GPL, or *BSD license without the
advertising clause.
It is important to note that the commercial OS vendors, and peripheral
vendors are relying on the Linux Community to perform the "daunting"
task of writing the UDI device drivers. Below is another brief quote
from the first URL.
<Begin Quote>
However, writing new drivers for the thousands of peripherals on
the market is a daunting task. Hence, Project UDI is hoping the
Linux community will help. Linux will be, said Quick, key to
the
adoption of the UDI initiative. A reference platform will be
distibributed as freeware for Linux, and the Project UDI members
will be counting on the Linux community to work on device drivers.
"We have talked to Linus Torvalds (the creator of Linux) and he
was very interested in the idea," Intel's Demshki said.
<End Quote>
The first two lines are of special interest to the Linux Community:
"However, writing new drivers for the thousands of peripherals on
the market is a daunting task. Hence, Project UDI is hoping the
Linux Community will help."
Another important phrase in this quote is made by Mr. Quick:
"Linux will be, said Quick, key to the adoption of the UDI initiative."
Perhaps David would be able to have Mr. Quick clarify his statements?
Please note that no where in the first URL web page are there any
statements
concerning either the commercial OS vendors supporting Linux or the
peripheral vendors supporting Linux with UDI drivers. The entire point
of the article is that the Project UDI, the commercial OS vendors, and
peripheral vendors are "hoping" that the Linux Community takes on this
"daunting" task.
Given that Mr. Quick is clearly indicating that Linux and thereby the
Linux
Community are "the key is adoption of the UDI initiative", it would seem
to
me that this places the Linux Community in an extremely awkward
position.
If we do not support Project UDI, it will be because of "us" that
Project UDI
"died on the vine". This would also seem to run the risk of being
labeled,
"unsupportive", "you can not count on the Linux Community for support",
"contrary", etc.
If we do support Project UDI, and the UDI device drivers are only
released
under GNU GPL, will we not also be labeled? Yes we supported Project
UDI,
but no one other than Linux is able to use the UDI drivers.
Please also note that neither the Porject UDI nor the ZDnet article Web
Page
give any indication that all the peripheral vendors will provide the
needed/wanted/desired/required technical documentation that would be
needed
to write the UDI device drivers. There are two peripheral vendors
mentioned
on the Project UDI Web Page namely Adaptec (recently joined Linux
International),
and Interphase.
There is also no mention of any of the video chip manufactuerers backing
Project
UDI. Having worked on the XFree86 project in the past, we would need the
support of S3, Cirrus Logic, etc.
Assume the Linux Community does support Project UDI there is still no
guarantee
that each and every peripheral marketed will be supported. If some
commercial
OS vendor can not make sales because there is no UDI driver for some
clients
particular brand/model/make/etc of peripheral card is the Linux
Community going
to be blamed for the lack of support?
In some respect Mr. Quick has jumped the gun by making these statements.
The UDI reference platform is not due out till February 1999 when the
complete
specification is released at the next Intel Developer Forum. It is not
until
then that the Linux Community particularly Linus sees what changes would
be
required to the Linux kernel to accomadate the UDI device drivers.
Given the awkward position that Mr. Quick and Intel representatives have
placed the Linux Community by this annoucement, what is going to be the
reaction of those outside of the Linux Community if Linus decides not
to accomadate UDI?
I am open to suggestions.
I again see only two good solutions to the current awkward position
Mr. Quick seems to have placed both Project UDI, and the Linux
Community in.
There are basically only two ways this UDI scenario can work.
1. All the commercial backers of it, switch to using Linux for their OS
and they just build hardware, or in SCO's case additional software
add-ons.
2. SCO releases all UNIX source code under the GNU GPL,
HP releases all sources code of HP-UX,
Sun releases all source code for SunOS and Solaris.
You might as well ask Apple to release all the source code to
NextStep/OpenStep/Rhapsody.
In either scenario there would be no problem if the UDI drivers were
released only under the GNU GPL.
Once again I ask who is going to represent the Linux Community in this
current situation? It is clear that someone preferablly a couple of
people should represent the Linux Community, and keep the rest of the
Community informed of the current status of Project UDI, the
reference platform, and the release of the complete UDI specification.
Since the commercial OS vendors, and peripheral vendors are making it
known here and now that Linux is the key to UDI adoption, and that the
Linux Community is being asked to help in the "daunting" task of writing
the UDI drivers so that the commercial OS vendors can use our work as
a basis, we as a community better have some say in the Project UDI.
David Hollister wrote:
>
> Terry L Ridder wrote:
> >
> > Hello;
> >
> > There are basically only two ways this UDI scenario can work.
> >
> > 1. All the commercial backers of it, switch to using Linux for their OS
> > and they just build hardware, or in SCO's case additional software
> > add-ons.
>
> In addition to what I say below, I don't understand what you're getting
> at by this statement either.
>
> > 2. SCO releases all UNIX source code under the GNU GPL, HP releases all
> > sources code of HP-UX, Sun releases all source code for SunOS and
> > Solaris.
> > You might as well ask Apple to release all the source code to
> > NextStep/OpenStep/
> > Rhapsody.
>
> Why would the OS guys have to release their OS source code? Their
> source code has nothing to do with a Linux driver written to conform to
> UDI. The only piece of UDI code that is of any real concern to the
> Linux community is the Linux OS environment piece. THAT would have to
> be released under the GPL for it to be publicly accepted. Anybody who
> wrote UDI drivers for Linux would also want to release their drivers
> under the GPL. In that case, the entire Linux UDI driver environment is
> then released GPL. What does HP-UX, SunOS, etc. have to do with
> anything?
Please see above.
>
> Maybe I'm misunderstanding your point... Or maybe there is a lack of
> understanding by many about how UDI is architected.
>
> --
> David Hollister Interphase Corporation dholl...@iphase.com
> Software Engineer Dallas, TX
--
Terry L. Ridder
Blue Danube Software (Blaue Donau Software)
"We do not write software, we compose it."
When the toast is burnt
and all the milk has turned
and Captain Crunch is waving farewell
when the Big One finds you
may this song remind you that they
don't serve breakfast in hell
==Breakfast==Newsboys
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: dholl...@Iphase.COM (David Hollister)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/19
Message-ID: <3603C1B9.2D6279A2@iphase.com>#1/1
X-Deja-AN: 392743478
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980918104155.560B-100000@lo-pc3035a>
Organization: Interphase Corporation
Newsgroups: muc.lists.linux-kernel
Terry et.al,
Maybe I should have done a little more research before opening my
mouth. I don't claim to be a UDI expert, a licensing expert, or
anything of the sort. Terry has evidently done a lot more research into
this whole thing than I have, which is great.
I'm in a somewhat awkward position anyway since I opened my big mouth.
Kevin is my boss. Now, as far as I know, his feelings about Linux are
the same as mine, we're both pro-Linux. What his other motivations
regarding Linux and UDI are, I can only guess. I have nothing to do
with UDI. I've seen bits of UDI code, but to be honest it never really
interested me much (I'm busy enough already). I've only taken an
interest in it now because it is obviously a major point of contention
in the Linux community (which I feel I'm part of, even if a very small
part).
Anyway, enough rambling. I'm going to be in Dallas next week (I work in
Arizona). I will take this email to Kevin and sit down with him and
discuss it. I'll come back to you all with his comments later next week
(I'm pretty sure I'm the only Interphaser reading this list)
Terry L Ridder wrote:
>
> Hello;
>
> For background on my comments I would suggest reading the original
> reports at:
>
> IT Week: Intel looks to Linux community for help with UDI
> http://www.zdnet.co.uk/news/1998/37/ns-5501.html
>
> A Brief Quote from the above article is below
>
> <Begin Quote>
> "The advantage of releasing to the Linux community is that their
> work will give Unix OS vendors a basis to work from," Quick added,
> though he stressed that the specification will still be tightly
> controlled and standards based.
> <End Quote>
>
> Uniform Driver Interface (UDI)
> http://www.sco.com/udi/
>
> Below is a brief quote from the above Web Page:
>
> [rest of message snipped for brevity]
--
David Hollister Interphase Corporation dholl...@iphase.com
Software Engineer Dallas, TX
http://www.public.asu.edu/~dhollist
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: k...@sch57.msk.ru (Khimenko Victor)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/19
Message-ID: <ABDFz0suqH@khim.mccme.ru>
X-Deja-AN: 392766495
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <3603C1B9.2D6279A2@iphase.com>
Organization: MCCME
Newsgroups: muc.lists.linux-kernel
In <3603C1B9.2D627...@iphase.com> David Hollister (dholl...@Iphase.COM) wrote:
DH> Terry et.al,
DH> Maybe I should have done a little more research before opening my
DH> mouth. I don't claim to be a UDI expert, a licensing expert, or
DH> anything of the sort. Terry has evidently done a lot more research into
DH> this whole thing than I have, which is great.
But Terry still wrong. There are is GPL and even more important there is
additional Linus clause about possibility of binary drivers for Linux.
So we have three choices for UDI drivers:
1. GNU GPL'ed UDI drivers or similar. Linux community are happy. [Some] Unix
vendors are unhappy. [Some] hardware manufacturers are unhappy.
2. GNU LGPL'ed UDI drivers or similar. Linux community are content. Unix
vendors are content. [Some] hardware manufacturers are unhappy.
3. Closed-Source UDI drivers. Linux community is unhappy. [Some] Unix
verndors are content, some are unhappy. Hardware manufacturers are
happy.
GPL and LGPL are different licensies. Main difference between GPL and LGPL is
that LGPL'ed work could be linked with closed-source code (like HP-UX or
SCO Unix source code). It's not clear for now that usage of drivers is
linking (in some systems (like Linux :-) you could load driver from module
and I'm not sure that it's could be classified as linking) but anyway:
"GPL problem" is not so big as Terry claims. UDI developers must be forced
to use LGPL and not GPL. But the biggest problem raised by UDI for Linux
community is Closed-Source drivers! Since Linux kernel API is in constant
change all existing closed-source drivers are in "unsupported" state (for
example change of kernel internals in 2.0.35 broke some Network Drivers)
and users are aware about this (even novices :-) and most of them avoid
closed-source drivers as much as they can (plus usually it's hard to find
that drivers -- you must search then on manufacturer web-site, you ubviously
could not find them on attached CD with drivers). UDI could change this and
manufacturers will produce it's own buggy UDI drivers and WILL NOT release
specs! Linux will be dependant from closed-source drivers (and often even
more buggy then Windows drivers since at least in this century *nix (includind
Linux) will be mandatory). That's point: UDI could help produce more buggy
Closed-Source drivers and will harm producing of Open-Source drivers (since
more and more manufacturers will not publish specs but instead will produce
Closed-Source UDI drivers and claims: "you already have drivers what else you
need???"). Even if UDI is NOT created with this scenario in mind it's HIGHLY
possible scenario and that's why Linux community just now is mostly against
UDI. [Most of] linux community is NOT against usage of UDI drivers tuned and
tested under Linux in HP-UX, SCO Unix, Solaris, etc. [Most of] linux community
is affraid of changing from their current Open-Source drivers to Closed-Source
UDI drivers.
DH> I'm in a somewhat awkward position anyway since I opened my big mouth.
DH> Kevin is my boss. Now, as far as I know, his feelings about Linux are
DH> the same as mine, we're both pro-Linux. What his other motivations
DH> regarding Linux and UDI are, I can only guess. I have nothing to do
DH> with UDI. I've seen bits of UDI code, but to be honest it never really
DH> interested me much (I'm busy enough already). I've only taken an
DH> interest in it now because it is obviously a major point of contention
DH> in the Linux community (which I feel I'm part of, even if a very small
DH> part).
Even if UDI initiative is created without bad minds in back it's still
HIGHLY possible then UDI will harm Linux in long terms (how -- see above).
And since this initiative has deep support from active I2O participants
(SCO & Intel) most Linuxoids (like me) are pretty sure that this is exactly
desirable scenario! I2O looks like it was specially created to give
closed-source players (Windows, SCO, HP-UX, Solaris, etc.) advantage oven
open-source players (Linux, *BSD, Hurd). JUST NOW UDI looks the same: force
Linux to use binary-only drivers, add check for OS in this drivers and make
drivers buggy under Linux (*BSD, Hurd) -- just few checks for OS type (a-la
Windows 3.1 beta) is enough -- and Ok under other OS'es; then clain that
Linux is buggy since it's crashed way to often. More subtle try then I2O but
still... You must coordinate a lot of manufacturers (not all of them -- only
few ones: one driver specially maked buggy is enough to crash Linux) but M$
has deep pockets...
DH> Anyway, enough rambling. I'm going to be in Dallas next week (I work in
DH> Arizona). I will take this email to Kevin and sit down with him and
DH> discuss it. I'll come back to you all with his comments later next week
DH> (I'm pretty sure I'm the only Interphaser reading this list)
DH> Terry L Ridder wrote:
>>
>> Hello;
>>
>> For background on my comments I would suggest reading the original
>> reports at:
>>
>> IT Week: Intel looks to Linux community for help with UDI
>> http://www.zdnet.co.uk/news/1998/37/ns-5501.html
>>
>> A Brief Quote from the above article is below
>>
>> <Begin Quote>
>> "The advantage of releasing to the Linux community is that their
>> work will give Unix OS vendors a basis to work from," Quick added,
>> though he stressed that the specification will still be tightly
>> controlled and standards based.
>> <End Quote>
>>
>> Uniform Driver Interface (UDI)
>> http://www.sco.com/udi/
>>
>> Below is a brief quote from the above Web Page:
>>
>> [rest of message snipped for brevity]
DH> --
DH> David Hollister Interphase Corporation dholl...@iphase.com
DH> Software Engineer Dallas, TX
DH> http://www.public.asu.edu/~dhollist
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: e...@arbat.com (Erik Corry)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/19
Message-ID: <19980919193105.A22160@arbat.com>#1/1
X-Deja-AN: 392784994
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
In article <ABDFz0s...@khim.mccme.ru> you wrote:
> But Terry still wrong. There are is GPL and even more important there is
> additional Linus clause about possibility of binary drivers for Linux.
> So we have three choices for UDI drivers:
> 1. GNU GPL'ed UDI drivers or similar. Linux community are happy. [Some] Unix
> vendors are unhappy. [Some] hardware manufacturers are unhappy.
> 2. GNU LGPL'ed UDI drivers or similar. Linux community are content. Unix
> vendors are content. [Some] hardware manufacturers are unhappy.
> 3. Closed-Source UDI drivers. Linux community is unhappy. [Some] Unix
> verndors are content, some are unhappy. Hardware manufacturers are
> happy.
But you can release a UDI driver simultaneously under two
different licenses. So everyone can be happy.
I think it is in the hardware manufacturers interest to
release their UDI driver under the GPL or the XFree86
license because.
1) It costs them nothing. 2) It gets taken up in the
standard kernel, which reduces the work for them.
3) It means they can sell to non-x86 (and later non-Merced)
Linux users
4) Someone might use the UDI driver to make a native Linux
driver which is almost certain to have better
performance.
5) It makes them look good. 6) Non-Linux Non-mainstream
OSs can use it too, without having to bother the
hardware manufacturer for a precompiled version (if
they use GPL then this applies to individual users of
the other OS, if they use XFree86 licensing the driver
can go into the standard distribution of ARM-OpenBSD
or whatever.
7) People who insist on source for security reasons
or other reasons can use the hardware too.
8) People will send them bug fixes, which they can use for
non-source UDI platforms
9) Users who want to be able to file bug reports to Red Hat
etc. and the kernel list will be able to use their
hardware. I would imagine that the kernel developers
will not want to waste their time trying to debug
kernels that contain non-source UDI drivers.
If the hardware manufacturer doesn't see this then we
can recommend users not to buy from them like we do now.
I don't believe in the doomsday scenarios, on the contrary
I think this could usher in a new age, where drivers for
new hardware are available immediately instead of several
months later. It is often a frustrating experience
loading Linux on a brand new machine, because being
brand new it has new hardware, where the drivers are
untested or unavailable. Three months later it is easy
but people don't generally buy three month old machines.
That turnaround time could improve dramatically.
--
There's really no way to fix this, and still keep Perl pathologically eclectic
--
Erik Corry e...@arbat.com Ceterum censeo, Microsoftem esse delendam!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: k...@sch57.msk.ru (Khimenko Victor)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/19
Message-ID: <AB-X_0sSDF@khim.mccme.ru>#1/1
X-Deja-AN: 392801939
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <19980919193105.A22160@arbat.com>
Organization: MCCME
Newsgroups: muc.lists.linux-kernel
In <19980919193105.A22...@arbat.com> Erik Corry (e...@arbat.com) wrote:
EC> In article <ABDFz0s...@khim.mccme.ru> you wrote:
>> But Terry still wrong. There are is GPL and even more important there is
>> additional Linus clause about possibility of binary drivers for Linux.
>> So we have three choices for UDI drivers:
>> 1. GNU GPL'ed UDI drivers or similar. Linux community are happy. [Some] Unix
>> vendors are unhappy. [Some] hardware manufacturers are unhappy.
>> 2. GNU LGPL'ed UDI drivers or similar. Linux community are content. Unix
>> vendors are content. [Some] hardware manufacturers are unhappy.
>> 3. Closed-Source UDI drivers. Linux community is unhappy. [Some] Unix
>> verndors are content, some are unhappy. Hardware manufacturers are
>> happy.
EC> But you can release a UDI driver simultaneously under two
EC> different licenses. So everyone can be happy.
Not at all. LGPL will be 100% enough for such purposes. Even preferred. Problem
is only for manufacturers: they are effectively forced to give away specs for
hardware without NDA's. This is EXACTLY what most of hardware manufacturers
dislike to do.
EC> I think it is in the hardware manufacturers interest to
EC> release their UDI driver under the GPL or the XFree86
EC> license because.
EC> 1) It costs them nothing. 2) It gets taken up in the
EC> standard kernel, which reduces the work for them.
EC> 3) It means they can sell to non-x86 (and later non-Merced)
EC> Linux users
EC> 4) Someone might use the UDI driver to make a native Linux
EC> driver which is almost certain to have better
EC> performance.
EC> 5) It makes them look good. 6) Non-Linux Non-mainstream
EC> OSs can use it too, without having to bother the
EC> hardware manufacturer for a precompiled version (if
EC> they use GPL then this applies to individual users of
EC> the other OS, if they use XFree86 licensing the driver
EC> can go into the standard distribution of ARM-OpenBSD
EC> or whatever.
EC> 7) People who insist on source for security reasons
EC> or other reasons can use the hardware too.
EC> 8) People will send them bug fixes, which they can use for
EC> non-source UDI platforms
EC> 9) Users who want to be able to file bug reports to Red Hat
EC> etc. and the kernel list will be able to use their
EC> hardware. I would imagine that the kernel developers
EC> will not want to waste their time trying to debug
EC> kernels that contain non-source UDI drivers.
EC> If the hardware manufacturer doesn't see this then we
EC> can recommend users not to buy from them like we do now.
When drivers just could not be used with recend kernel versions (as of now)
it's trivial. UDI will make this hard to do. Plus most Linux users in 21th
century will be "Joe Averages" who will not be bothered by such obscure
things and who will be sure that it's Linux fault if Linux constantly made
kernel oopses even if they are using buggy binary-only drivers...
EC> I don't believe in the doomsday scenarios, on the contrary
EC> I think this could usher in a new age, where drivers for
EC> new hardware are available immediately instead of several
EC> months later. It is often a frustrating experience
EC> loading Linux on a brand new machine, because being
EC> brand new it has new hardware, where the drivers are
EC> untested or unavailable. Three months later it is easy
EC> but people don't generally buy three month old machines.
EC> That turnaround time could improve dramatically.
Yes. But this will effectively mean for hardware manufacturers that they are
forced to publish specs for their hardware. I'm not think that manufacturers
will be happy to do this :-(( Of course this is the only disadvantage for
manufacturers but look like some of them REALLY hate to give away specs...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: e...@arbat.com (Erik Corry)
Subject: Re: Linux, UDI and SCO.
Date: 1998/09/19
Message-ID: <19980919203721.A25556@arbat.com>#1/1
X-Deja-AN: 392809326
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <19980919193105.A22160@arbat.com>
Newsgroups: muc.lists.linux-kernel
On Sat, Sep 19, 1998 at 10:31:26PM +0400, Khimenko Victor wrote:
> In <19980919193105.A22...@arbat.com> Erik Corry (e...@arbat.com) wrote:
>
> EC> But you can release a UDI driver simultaneously under two
> EC> different licenses. So everyone can be happy.
>
> Not at all. LGPL will be 100% enough for such purposes.
I see no way of forcing hardware manufacturers to use LGPL.
The only way would seem to be to not put UDI in the official
kernel, but there are sure to be distributions that put it
in anyway (Xi graphics will, I would guess) and individuals
will always be free to do so.
--
Erik Corry e...@arbat.com Ceterum censeo, Microsoftem esse delendam!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: emars...@logic.net (Edward S. Marshall)
Subject: UDI and Politics (was Re: Linux, UDI and SCO.)
Date: 1998/09/19
Message-ID: <Pine.LNX.3.96.980919150244.10176C-100000@labyrinth.logic.net>#1/1
X-Deja-AN: 392835150
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <19980919203721.A25556@arbat.com>
Newsgroups: muc.lists.linux-kernel
On Sat, 19 Sep 1998, Erik Corry wrote:
> The only way would seem to be to not put UDI in the official
> kernel, but there are sure to be distributions that put it
> in anyway
I think this is something this discussion has been seriously missing;
input from some of those who really will be deciding this:
- Linus Torvalds and other kernel developers (Alan's been involved a bit,
though).
- Distribution vendors (RedHat, Debian, SuSE, Slackware, Stampede, etc)
These are the people who will really choose what direction Linux goes in
on this one, just because what they do will shape what the end user
inevitably sees (the average end user is not someone who compiles their
own kernel; the end user is someone who goes to the store and buys a CD
from some distribution vendor; and those distribution vendors generally
follow the lead that Linus and Co. provide). I'm extremely interested in
hearing an official (or unofficial) point of view from them at this point.
Personally, I'm leaning toward the camp that has a problem with UDI; not
as a concept (interoperability is always a good thing), but because of the
problems it can potentially raise with giving vendors an excuse to only
develop a single Intel-based UDI driver, and not release source or specs,
locking out the other platforms that Linux operates on (even if the device
can technically be used on other architectures).
Lack of specs locks Linux out of the OS market in the long run, as more
and more drivers are developed under NDAs and sold commercially (which
mean they cannot be distributed with the kernel). While I agree with UDI
in spirit, I can't agree with the effect it will have on the hardware
vendor decision-making process.
--
-------------------. emarshal at logic.net .---------------------------------
Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/
Linux labyrinth 2.1.117 #2 SMP Thu Aug 20 21:20:49 CDT 1998 i586 unknown
3:00pm up 7 days, 16:43, 3 users, load average: 0.00, 0.00, 0.00
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: ty...@MIT.EDU (Theodore Y. Ts'o)
Subject: Re: UDI and Politics (was Re: Linux, UDI and SCO.)
Date: 1998/09/19
Message-ID: <199809192235.SAA08247@dcl.MIT.EDU>#1/1
X-Deja-AN: 392862151
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980919150244.10176C-100000@labyrinth.logic.net>
Newsgroups: muc.lists.linux-kernel
Date: Sat, 19 Sep 1998 15:12:55 -0500 (CDT)
From: "Edward S. Marshall" <emars...@logic.net>
I think this is something this discussion has been seriously missing;
input from some of those who really will be deciding this:
- Linus Torvalds and other kernel developers (Alan's been involved a bit,
though).
Well, not that anything I saw is official in any way, but I've been
keeping quite because I've been amazed how stupid most of the UDI
discussion has been.
Let's back off and have a fresh perspective on things.
First of all, from looking at the UDI spec, UDI drivers will likely not
be as performant as "native" drivers. So there will still be incentives
for people who want device drivers for Linux to actually go and write
them, and for those people to pester manufactuers for specifications.
(Or reverse-engineer or disassemble the UDI driver for programming
information. :-)
Secondly, UDI drivers will almost certainly be loadable kernel modules,
using a fixed, and well defined interface. Linus (as the main copyright
holder of the Linux kernel) has already said that loadable kernel
modules which restrict themselves to the kernel interface as defined by
/proc/ksyms are considered separate entities, and are not covered by the
GPL copyright --- just as user programs which use the normal kernel
system calls are not considered part of the kernel, but using normal
kernel services. So all of the copyright arguments are also a red
herring.
Furthermore, what do you think the APM code in the Linux kernel does?
It makes calls to the APM BIOS! Or the Linux Bootstrap code, which
makes calls to the system BIOS. The System BIOS and the APM BIOS are
not GPL'ed on most systems --- indeed, source code is usually not
available in any form. Why is this not a problem?
Well, let's think about it. The System BIOS and APM BIOS have a
well-defined, and standardized interface. When you buy a computer, it
comes with BIOS installed on ROM's as a matter of course. So the fact
that the System BIOS and the APM BIOS are not free doesn't get people's
way, and they probably simply don't think about it.
Similarly, suppose now that network cards start coming with UDI drivers
on a diskette as a matter of course. The UDI device driver uses a
standardized, well-defined interface --- the UDI interface. It really
isn't all that different from the Linux kernel calling system BIOS
routines, or the APM routines.
So fundamentally, I don't have a problem with the UDI concept --- just
as I don't have a problem with purchasing commercial software to run on
my Linux box. I am not an Open Source fanatic. All other things being
equal, I prefer Open Source, of course, but if a Open Source product
doesn't exist, and there is a good propietary solution available, I will
use it.
The big question, though is the quality of the UDI reference
implementation which SCO is planning on writing. WIll it be clean
enough so that Linus is willing to include it in the mainline kernel?
That's the $64,000 question. If it's big, ugly, etc., then the answer
will be no. And of course, the UDI reference implementation which will
actually *allow* the Linux kernel to take advantage of UDI drivers will
have to be GPL'ed, since that *will* be linked with the kernel in a very
fundamental way. But as far as I can tell, SCO understands that.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: UDI and Politics (was Re: Linux, UDI and SCO.)
Date: 1998/09/20
Message-ID: <m0zKb6o-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 392910884
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980919150244.10176C-100000@labyrinth.logic.net>
Newsgroups: muc.lists.linux-kernel
> - Linus Torvalds and other kernel developers (Alan's been involved a bit,
> though).
Im not interested in UDI. If SCO want to show a miraculous change of heart
let them as a major member of the I2O consortium get the documentation
that opened. The stuff in the drafts they accidentally let for anonymous
FTP showed I2O would work very well with Linux and its configure and
i960 side device interfaces are reasonably well designed and truely
OS independant
While SCO have their left hand on the I2O binary sword I can't take the open
right hand terribly seriously.
But thats a personal viewpoint
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/