Linux-Development-Sys Digest #365, Volume #8 Wed, 20 Dec 00 15:13:15 EST
Contents:
module mismatch. (Stephen Lohning)
Re: Problems with C++ in Kernel Module (Rui Antunes)
Re: module mismatch. (Richard Kolb)
OT: stupid democrats? ([EMAIL PROTECTED])
Re: RAD environments ("Matthew Smith")
Re: module mismatch. (Bill Waddington)
OT: Election (was: Compiling C++ programs with GCC --> no GPL license ("Jeffrey B.
Siegal")
[OT] Re: Compiling C++ programs with GCC --> no GPL license implications (Stefaan A
Eeckels)
Re: Problem compiling kernel. (Karen Gartner)
Re: Getting eth0 device information in C or perl. (Fraser Stewart)
Re: c++ linux kernel question (Kaz Kylheku)
ramfs root(/) explained ("Repairlix")
Re: mounting RAMFS as / ("urp")
Re: Intel Easy PC camera - cannot be supported in Linux! (Jonathan Buzzard)
Re: Problem compiling kernel. (Toby Haynes)
(byteme)
Re: Intel Easy PC camera - cannot be supported in Linux! (mlw)
----------------------------------------------------------------------------
From: Stephen Lohning <[EMAIL PROTECTED]>
Crossposted-To: redhat.kernel.general
Subject: module mismatch.
Date: Thu, 21 Dec 2000 00:10:44 +1100
I am trying to write a pci driver for a card we developed which uses a
PLX9050 chip.
I am using a driver developed for a me2600 data aquistion card as a
reference.
I have the bare shell of the module compiling when I try loadng the
module
in insmod xxmul.o I get the following error message.
xxmul.o: kernel-module version mismatch
xxmul.o was compiled for version 2.4.0-0.26 while the kernel
is version 2.2.16-22
Note I am running RH7.0
Do I have to recompile my kernel ?
Do I need to upgrade the version of gcc ?
Is there any need to upgrade the kernel past 2.2.16-22 at the moment?
What is kgcc ?
My pc is a dual pentium which can run smp ok. Should I try using the
uni- processor version while I am developing my driver. Lower the
level of complexity.
------------------------------
From: [EMAIL PROTECTED] (Rui Antunes)
Subject: Re: Problems with C++ in Kernel Module
Date: Wed, 20 Dec 2000 13:50:51 GMT
Thanks for all your help. I already knew that I would have to create
something like new() and delete()... My question is - everything else
work?
- if I declare an (function-scope) instance of a certain class is the
proper contructor (and afterwards, the destructor) called? (I
understand that global-scope instances aren't...)
- does function overloading still work (functions with same name but
with different number or type of arguments)?
Now a C++ question: what's the difference between a pure virtual
method and a virtual method? Something like this...?
class A {
int data;
A(int dt);
~A();
virtual int func_virtual(void);
virtual int func_purevirtual(void) = 0;
}
int A::func_virtual(void)
{
return data;
}
So, it's __pure_virtual used only in a func_purevirtual() call or also
in a func_virtual() call?
In my new() alike function can I call the class constructor as if it
was any other method? Like:
A* newA(int dt) {
A* inst;
inst = kmalloc(sizeof(A),GFP_KERNEL);
inst.A(dt);
return inst;
}
And what about the class destructor - can it be used in a similiar
way?
void deleteA(A* inst) {
inst.~A();
kfree(inst);
}
Again, thanks for all your help,
Rui Antunes
On Mon, 18 Dec 2000 10:00:02 +0100, "O.Petzold"
<[EMAIL PROTECTED]> wrote:
>>
>> When I run "make" everything goes wll (apparently) - it compiles
>> and links without warnings or errors - but when I insmod it the
>> following errors are displayed:
>> unresolved symbol __builtin_delete
>> unresolved symbol __rtti_user
>> unresolved symbol __pure_virtual
>
>You have to bring your own new and delete (e.g. using kmalloc/kfree) and
>you can't use exceptions and rtti, since the startup code isn't ported to
>the kernel yet. (gcc -fno-exceptions -fno-rtti). At moment I try to port
>some of the code to the kernel (a priori exception handling). __pure_virtual
>is small "guard" that calls in user space abort(), since nobody should call
>a pure virtual function (e.g. as a result of c-casts..). There is a next problem -
>how to terminate a kernel module ??
>
>> Also, I can not include<linux/malloc.h> in bcipher.cc because
>> <linux/malloc.h> includes <linux/list.h> which declares a variable
>> with the name new --the C++ compiler returns an error probably because
>> it confuses it with the new() function; also it returns an error when
>> including <linux/signal.h> just because it has a switch() that in one
>> of the case: there is no instruction...
>
>Yep, some includes are a nightmare. The only solution for signal.h which I
>have is to patch it. The other is to
>extern "C" {
>#define new hide_new
>....
>#include <linux/malloc.h>
>#undef new
>....
>}
>
>> Is it a good idea to use C++ in the kernel (I don't use exceptions
>> nor anything too powerful) ? Alright, probably it isn't. But is it
>> possible (if the C++ code is relatively simple)?
>
>C++ has a big advantage concerning cleaning up the resources using the
>destructors. There is nothings equal to in C imo. The next is hiding the data
>etc. Well, on the other side, there are a lot of problems as you can see.
>The best would be to port the basic functionality to the kernel. Living
>without exceptions is possible but, it's a nightmare on shared files for
>user and kernel space since you have to ifdef/else/.. - that's my problem.
>The next would be to shadow the kernel header and than you can port
>parts of the libstdc++ (e.g. string - nesessary for some exceptions ..)
>
>Regards
>Olaf
>
>
>
------------------------------
From: Richard Kolb <[EMAIL PROTECTED]>
Crossposted-To: redhat.kernel.general
Subject: Re: module mismatch.
Date: Wed, 20 Dec 2000 16:20:03 +0200
Stephen Lohning wrote:
> I am trying to write a pci driver for a card we developed which uses a
> PLX9050 chip.
> I am using a driver developed for a me2600 data aquistion card as a
> reference.
> I have the bare shell of the module compiling when I try loadng the
> module
> in insmod xxmul.o I get the following error message.
>
> xxmul.o: kernel-module version mismatch
> xxmul.o was compiled for version 2.4.0-0.26 while the kernel
> is version 2.2.16-22
>
> Note I am running RH7.0
> Do I have to recompile my kernel ?
> Do I need to upgrade the version of gcc ?
> Is there any need to upgrade the kernel past 2.2.16-22 at the moment?
> What is kgcc ?
>
> My pc is a dual pentium which can run smp ok. Should I try using the
> uni- processor version while I am developing my driver. Lower the
> level of complexity.
When you compile your module it includes version information from one of
the header files.
This is where 2.4.0-0.26
Your kernel is 2.2.16-22
This is protecting against version , since the linux kernel changes a
lot.
(You can froce it, but I don't suggest this )
All you need to rectify this is have the same kernel source as binary
kernel that you are booting.
Also a general rule of thumb, Stay away from redhat 7.0 , it's got a
broken version of gcc , that was not supposed to be released.
Posting by Linus, http://linuxgram.com/newsitem.phtml?sid=109&aid=11453
Richard.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Subject: OT: stupid democrats?
Date: 20 Dec 2000 09:56:20 -0500
Followup-To: gnu.misc.discuss
(least off-topic of all the newsgroups, though still OT)
[EMAIL PROTECTED] (Sam Holden) writes:
> The recount should have no effect since the chance of a rejection
> should be the same no matter who the vote was for. I can only guess
> that there were more stupid people who voted democrat, or more weak
> people who can't punch a hole in a ballot who voted democrat, or more
> not working correctly machines in democrat leaning polling
> booths. None of those options seem very satisfactory.
Poorer precincts tend to vote democratic, and poorer precincts have
older/worse equipment with higher error rates.
The other issue is the Dade County butterfly ballot. An article at
http://www.larrysworld.com/articles/ups_ballot.htm
has a link to a photo of it.
If you take a thorough look at the whole ballot, it's clear what hole
goes with what candidate. However, for someone less careful or with
poor eyesight, it might not be clear that you need to punch the third
hole down to vote for the second candidate on the list. You might not
realize that the arrow from the number 5 to the third hole is actually
telling you how to vote for the second candidate.
If you're voting for Bush, there's no confusion because the top hole
goes with the top candidate. But it's no surpise that a small
percentage of voters who intended a Gore vote ended up with a Buchanan
vote (the second hole). This cost Gore at least 2000 votes.
Dade County voters started complaining at 7:05a.m. of officials
illegally denying them a second ballot when they messed up the first
one. 19,000 double-punched ballots were rejected. I don't know how
much this has been followed up on.
We don't know if democratic voters are statistically more stupid than
republican voters, but we do know that the democratic officials who
(along with republican officials) approved the ballot didn't know much
about user interface issues.
> You Americans are going to have a fun 4 years I guess...
Yes, but don't blame Florida. They voted for Gore.
--
Bruce R. Lewis http://brl.sourceforge.net/
------------------------------
From: "Matthew Smith" <[EMAIL PROTECTED]>
Subject: Re: RAD environments
Date: Wed, 20 Dec 2000 07:57:49 -0000
You can replace the Windows CE on an iPaq with Linux :)
For RAD you have C *AND* C++ ;-)
------------------------------
From: Bill Waddington <[EMAIL PROTECTED]>
Crossposted-To: redhat.kernel.general
Subject: Re: module mismatch.
Date: Wed, 20 Dec 2000 14:50:27 GMT
In article <[EMAIL PROTECTED]>,
Stephen Lohning <[EMAIL PROTECTED]> wrote:
> I am trying to write a pci driver for a card we developed which uses a
> PLX9050 chip.
> I am using a driver developed for a me2600 data aquistion card as a
> reference.
> I have the bare shell of the module compiling when I try loadng the
> module
> in insmod xxmul.o I get the following error message.
>
> xxmul.o: kernel-module version mismatch
> xxmul.o was compiled for version 2.4.0-0.26 while the kernel
> is version 2.2.16-22
>
> Note I am running RH7.0
> Do I have to recompile my kernel ?
> Do I need to upgrade the version of gcc ?
> Is there any need to upgrade the kernel past 2.2.16-22 at the moment?
> What is kgcc ?
>
> My pc is a dual pentium which can run smp ok. Should I try using the
> uni- processor version while I am developing my driver. Lower the
> level of complexity.
>
>
Hello,
Try compiling with -I/usr/src/linux/include instead of -I/usr/include.
Maybe dumping RH7 would be a better idea.
Bill
--
Bill Waddington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Jeffrey B. Siegal" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Subject: OT: Election (was: Compiling C++ programs with GCC --> no GPL license
Date: Wed, 20 Dec 2000 07:32:24 -0800
Isaac wrote:
> I'd suggest that once the counting
> machine has been shown to be failing in some significant way, it would
> be foolish to simply hope that the machine is giving an accurate
> count.
The machines have always been *known* to be imperfect. It was known
that they will reject some valid ballots. It was known that they will
count some invalid ballots (for example, double-punched votes where one
of the punches isn't detected). The machines were designed to quickly,
and *reasonably* accurately -- not perfectly accurately -- count
ballots. Put a million ballots though the machines and some valid votes
will be discarded. I defy you to design any electro-mechanical device
where this is not the case. This is not about counting abstract bits,
but about counting physical cards which have been subject to all sorts
of abuse, mishandling, etc.
Whether the non-zero margin of error is enough to sway an election can
only be determined by reviewing all the ballots (or a sufficiently large
random sample). Looking at the ballots that were rejected as
uncountable by the machine tells you nothing. Recounting only those
votes in order to *add* votes, without considering ways in which counted
votes should be discarded, is inherently biased in favor of whichever
candidate is likely to have gotten more votes in the underlying
population (Gore, in this case).
I have nothing against counting *all* the votes according to a
predetermined objective standard, by hand, improved machines, whatever.
But don't fall for the political spin that was thrown around about
"disenfranchised voters" and the need to "count all the votes." The
stink about recounting only the undervotes -- like just about everything
you have heard coming out of Flordia)over the past two months, from both
sides, was just that -- part of a deliberte spin campaign designed by
each side to get its own candidate elected.
Like you, I am tired of this issue. Time to move on. Considering that
and the fact that this is way off topic for this forum, I will almost
certainly not be replying again.
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: [OT] Re: Compiling C++ programs with GCC --> no GPL license implications
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Date: Wed, 20 Dec 2000 16:03:45 +0100
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Isaac) writes:
> On Wed, 20 Dec 2000 02:27:13 -0800, Jeffrey B. Siegal <[EMAIL PROTECTED]> wrote:
>>
>>Also, if you were to audit the machines to determine if they were
>>working within their design parameters, you'd want to hand-count either
>>all the votes, or a random sample thereof. Just examining the votes
>>that get spit out uncounted do not objectively measure whether the
>>machine is working properly overall. (It might be double counting other
>>ballots, which would partially cancel the effect of uncounted ballots,
>>for example.)
> I said I would stay out of this, but I guess seeing my position
> mischaracterized was too much.
>
> If the uncounted votes were examined and found to contain votes which
> by design should have been counted, I think that does objectively show
> the machine to be working improperly in at least one fashion. I agree
> that you cannot verify that the machine does or does not have other
> problems only by looking at the uncounted ballots.
>
> You then seem to be saying if a machine is shown to be improperly rejecting
> votes, that is not an objective measurement because there might be an
> additional compensating flaw. I'd suggest that once the counting
> machine has been shown to be failing in some significant way, it would
> be foolish to simply hope that the machine is giving an accurate
> count. In fact it's highly unlikely that it would be doing so.
> Assuming the number of uncounted votes is small compared to
> the total, and statistically significant, checking them first to
> make sure the machine was rejecting only what it was designed to reject
> seems prudent and expedient.
I'm dragging you further into it, Isaac - my not so
sincere apologies :-)
The machine should have been tested and calibrated before
the elections. One would assume that a system to calibrate
the machines is available, using a well-know test deck.
It's no use checking the rejected ballots _after_ the vote,
as a malfunctioning _counting_ machine might have rejected
good ballots, and accepted bad ones. The only method is to
have the ballots recounted by another machine, and compare
its results with the results of the contested machine.
None of this requires a _manual_ recount, just pushing
the decks through enough different machines to get a reliable
count.
The problem in Florida was, if I understood it correctly,
not one of malfunctioning card readers, but that the device
used by the voters to punch the cards was deficient, or
not sufficiently easy to operate. The recounting consisted
of four people gazing at the cards trying to intuit what
the voter intended, on what are essentially _invalid_
ballots. The voter should have insured the card was punched
properly.
A second problem was entirely different, and concerned the
misleading layout of the ballot papers in a particular
county, and is in no way related to machines counting or
not counting votes.
--
Stefaan
--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
------------------------------
From: Karen Gartner <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.install
Subject: Re: Problem compiling kernel.
Date: Wed, 20 Dec 2000 18:15:33 GMT
I have EXACTLY the same error messages! I'm trying to
backstep to 2.2.14 (that's the only version my video drivers
will accept) from 2.2.16. Please email me when you find a
solution & I'll do the same for you.
I've left a msg in the linux.redhat group regarding my
Diamond Fire GL1 video card & trying to redo the kernel. Now
I know it's not to do with my card.
------------------------------
From: Fraser Stewart <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.networking,linux.dev.apps,linux.dev.c-programming,linux.dev.net,aus.computers.linux
Subject: Re: Getting eth0 device information in C or perl.
Date: Wed, 20 Dec 2000 18:41:23 +0000
michael scott frank wrote:
>
> If you want to do it in C, you use the ioctl SIOCGIFADDR. Here's a small
> program i wrote a while ago, modified a bit for what you need. Its a bit
> of work to do it the 'real' way, as you can see. the ifreq struct is
> particularily nasty, if you look at how it is defined in the headers. If
> you are interested in this stuff like i am tho, you should definitely pick
> up "UNIX network programming" by W. Richard Stevens. it is _the_ book on
> the subject, and has an excellent chapter on network related ioctls.
>
> #include <stdio.h>
> #include <sys/socket.h>
> #include <sys/ioctl.h>
> #include <netinet/in.h>
> #include <net/if.h>
>
> int main(void) {
> int fd;
> struct sockaddr_in *addr_ptr;
> <<<<SNIP>>>>>
Oops, I've just stolen that!
Luvly!
Fraser.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: linux.sources.kernel,comp.os.linux.embedded,gnu.g++.help
Subject: Re: c++ linux kernel question
Reply-To: [EMAIL PROTECTED]
Date: Wed, 20 Dec 2000 19:07:36 GMT
On Wed, 20 Dec 2000 13:55:13 +0100, O.Petzold <[EMAIL PROTECTED]> wrote:
>Hello,
>
>at moment I try to port some of the gcc-2.95.2 stuff to use c++
>in the linux kernel. I get no linker errors but I have a question.
>I thought __do_global_Xtors_aux is needed for global constructors,
>like if I have
>
>[...]
>ClassA;
>
>Class a;
The answer is not to have that.
>[...]
>
>I need these. But I get no linker errors as I excpected. Why this ?
You think you need these but you really don't. Because you can easily
replace
Class a;
with
Class *a;
then assign a value to the pointer a in your init_module().
>The other is related to exception handling. This isn't working yet.
What kind of a behemoth are you porting to the kernel anyway? What
exactly are you doing? What other kernels does this code run in already?
>The abort() is the next problem. How can I terminate a module,
>prefered is that the module removes itself. Anyway, where comes
>the symbol __this_module from ?
I think you still don't get it. A module is not like an application program.
It's just a chunk of code that runs in the context of the entire kernel. The
kernel equivalent of abort() is panic(). It brings down the whole system. You
must write the module such that such a thing never happens. Ideally, a
module should not have any calls to panic(); rather it should gracefully handle
every condition that may arise.
You cannot remove a module at just any old time. Removing a module is an action
that is initiated by the kernel, in response to a request from user space (like
the rmmod program being run, or the module deamon timing out an inactive
module). A module cannot be removed while the rest of the kernel still has
pointers to that module's code or data. For that reason, a module is associated
with a reference count, which must drop to zero before that module is
considered removable.
If something goes so wrong in a module that it can no longer execute, then it
should set some flag and return errors to processes that call it. It should
disable any callback routines and just wait to be shut down and removed.
------------------------------
From: "Repairlix" <[EMAIL PROTECTED]>
Subject: ramfs root(/) explained
Date: Wed, 20 Dec 2000 11:21:00 -0800
I have recently done a CVS update on Repairlix
(http://repairlix.sourceforge.net) with my updates for running a system
out of a root ramfs - Repairlix now actually does this.. My NOTES file
contains an adequate explanation of what you need to do. There's gotchas
galore in building a system this way and I've attempted to explain a few
of them.
The explanation is here, at the end:
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/NOTES?rev=1.20&content-type=text/x-cvsweb-markup&cvsroot=repairlix
But the actual shell script that does it is here:
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/rc.sysinit?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=repairlix
And finally, you may just want to do the whole CVS thing:
http://sourceforge.net/cvs/?group_id=9472
(The latest official file release doesn't contain any of this logic.)
------------------------------
From: "urp" <[EMAIL PROTECTED]>
Subject: Re: mounting RAMFS as /
Date: Wed, 20 Dec 2000 11:25:09 -0800
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> I would like to mount RAMFS (CONFIG_RAMFS) as / (not RAMDISK).
Check out this for an example:
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/rc.sysinit?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=repairlix
> What would I write into /proc/sys/kernel/real-root-dev to do this?
Your analysis was correct: there's no device, so there's nothing to write
to real-root-dev - that method just won't work. This is one of my pet peeves.
Whatever happened to "everything is a file" ?? :-)
------------------------------
From: [EMAIL PROTECTED] (Jonathan Buzzard)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.advocacy
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!
Date: Tue, 19 Dec 2000 21:46:49 +0000
In article <[EMAIL PROTECTED]>,
mlw <[EMAIL PROTECTED]> writes:
[SNIP]
>
> The price indicates that the actual camera is trivial and all the
> important product development was in the software. If Intel makes the
> hardware API public, then it is clear how the camera works. Competitors
> would be able to clone the hardware and just instruct users to download
> the camera software from Intel.
I don't think that this would work, few users would be happy not getting
the driver with the device, and it would probably be a breach of the
license for the software. If Intel was to put some device ID in the
device which the driver was to check, then this would effectively lock
out the clonners, unless they want to find themselves in court.
> I worked at Polaroid as a contractor and did some work on their
> electronic still camera. There is a lot of image processing involved in
> this sort of product. Obviously, the el-cheapo cameras must do this in
> host software, not on the camera to keep the costs down. The competitor
> only has to invest in hardware, while Intel has to recoup cost the
> larger cost of software development.
>
> It is a tough problem, and one of those gray areas in which a pure GPL
> approach is a very tough sell. To differentiate yourself and be
> competitive with a hardware product, you must make it good and make it
> competitively priced. The answer to this is proprietary software to
> control mass-produced trivial hardware.
>
Not in a pure GPL approach, as Intel would have only a small expense in
the software development as would all the other camera manuafactures.
JAB.
--
Jonathan A. Buzzard Email: [EMAIL PROTECTED]
Northumberland, United Kingdom. Tel: +44(0)1661-832195
------------------------------
From: Toby Haynes <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.install
Subject: Re: Problem compiling kernel.
Date: 20 Dec 2000 14:26:16 -0500
On Wed, 20 Dec 2000, [EMAIL PROTECTED] wrote:
> I have EXACTLY the same error messages! I'm trying to
> backstep to 2.2.14 (that's the only version my video drivers
> will accept) from 2.2.16. Please email me when you find a
> solution & I'll do the same for you.
>
> I've left a msg in the linux.redhat group regarding my
> Diamond Fire GL1 video card & trying to redo the kernel. Now
> I know it's not to do with my card.
If you are using Redhat 7.0, you MUST use kgcc (kernel gcc) and NOT gcc (which
is a CVS snapshot and not really suitable for kernel compilation). Check that
cc is actually pointing to kgcc, or explicitly set the compiler to be kgcc.
Cheers,
Toby Haynes
--
Toby Haynes
The views and opinions expressed in this message are my own, and do
not necessarily reflect those of IBM Canada.
------------------------------
From: [EMAIL PROTECTED] (byteme)
Subject:
Date: Wed, 20 Dec 2000 19:54:33 GMT
For an ans. to your original Q?.
Correct me if i'm wrong , but you seem to be asking wether or not
there exists a development enviroment for linux (ie. an IDE
interface)
If thats what your looking for. Yes there is it's called KDEVELOP and
is dist. by KDE desktop folks, But it probably isn't quite what your
looking for . It's not a point & click but it's pretty nice I
personaly don't like P&C Enviroments. There is also a proj. by
Borland to create a linux version of C++ Builder , can't think of the
name though. check out thier site.
kevin
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.advocacy
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!
Date: Wed, 20 Dec 2000 15:03:51 -0500
Jonathan Buzzard wrote:
>
> In article <[EMAIL PROTECTED]>,
> mlw <[EMAIL PROTECTED]> writes:
> [SNIP]
> >
> > The price indicates that the actual camera is trivial and all the
> > important product development was in the software. If Intel makes the
> > hardware API public, then it is clear how the camera works. Competitors
> > would be able to clone the hardware and just instruct users to download
> > the camera software from Intel.
>
> I don't think that this would work, few users would be happy not getting
> the driver with the device, and it would probably be a breach of the
> license for the software. If Intel was to put some device ID in the
> device which the driver was to check, then this would effectively lock
> out the clonners, unless they want to find themselves in court.
But, and I have seen this with older video cards based on S3 chips,
video capture cards, FAX modems, etc. If vendor A puts a lot of work in
their driver to make it better, and vendor B puts very little work in
their driver, but it is common knowledge that vendors A's driver will
work with vendor B's hardware, the more savvy people will buy the device
by vendor B and download drivers from vendor A.
>
> > I worked at Polaroid as a contractor and did some work on their
> > electronic still camera. There is a lot of image processing involved in
> > this sort of product. Obviously, the el-cheapo cameras must do this in
> > host software, not on the camera to keep the costs down. The competitor
> > only has to invest in hardware, while Intel has to recoup cost the
> > larger cost of software development.
> >
> > It is a tough problem, and one of those gray areas in which a pure GPL
> > approach is a very tough sell. To differentiate yourself and be
> > competitive with a hardware product, you must make it good and make it
> > competitively priced. The answer to this is proprietary software to
> > control mass-produced trivial hardware.
> >
>
> Not in a pure GPL approach, as Intel would have only a small expense in
> the software development as would all the other camera manuafactures.
But how would Intel make a case for its camera over some low priced
clone? Why would someone pay $10 dollars more for an Intel camera? They
wouldn't, and that would not be acceptable for someone like Intel.
Intel has a brand name, as dubious as it is, they have to make sure that
there camera is better than a "Snap!" super el-cheapo. If they can't,
they won't enter the market. If they release something that makes their
camera better than the "Snap!" then, "Snap!" would be able to copy their
image processing techniques and steal the market with price.
GPL can not apply to hardware, because hardware is limited by finite
numbers. Production has a proportional unit cost for the producer. While
the software associated with a digital camera may be free, making it so
would affect the ability to produce the camera competitively. The
software is part of the camera.
--
http://www.mohawksoft.com
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
