Linux-Development-Sys Digest #367, Volume #8 Thu, 21 Dec 00 07:13:10 EST
Contents:
PANIC: C++ in Kernel Module gives strange version error! (Rui Antunes)
Re: Char device drivers and mknod (Petric Frank)
Re: Intel Easy PC camera - cannot be supported in Linux! (jtnews)
Re: how to use "pthread_rwlock_t" in linux? ("Victor")
Re: [OT] Re: Compiling C++ programs with GCC --> no GPL license implications (Isaac)
Re: how to use "pthread_rwlock_t" in linux? (Kaz Kylheku)
Re: Intel Easy PC camera - cannot be supported in Linux! (Kaz Kylheku)
Re: c++ linux kernel question ("O.Petzold")
Re: PANIC: C++ in Kernel Module gives strange version error! ("O.Petzold")
Re: Linix terminal emulation software ("Geoff Winkless")
Re: ip_masq_ftp.c (Erik Hensema)
Re: Compiling C++ programs with GCC --> no GPL license implications ("Peter T.
Breuer")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Rui Antunes)
Subject: PANIC: C++ in Kernel Module gives strange version error!
Date: Thu, 21 Dec 2000 00:39:07 GMT
I had a LKM that worked just fine.
I had to add one or two C++ files (I swear, I really had to! and
it was either that or convert those C++ files to C code) and, after I
solved the include problems with <linux/malloc.h> (<linux/list.h> and
<linux/signal.h>) with some (hiding) definitions and after I patched
<linux/signal.h> (posted in this newgroup - thanks!) and after I
defined my __builtin_new and __builin_delete (and even __pure_virtual)
I finally got my module to compile.
However, when I insmod'ed it I got a slap in the face:
$ insmod tmp_module.o
tmp_module.o: couldn't find the kernel version the module was
compiled for
Why?!? (when I used no C++ code it worked fine!)
I'll leave here (part of) my makefile and (part of) my LKM code
just in case someone can understand why C++ in kernel module is like
Mission Impossible...
/* ===== LKM ===== */
extern "C" {
#define new hide_new
#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/module.h>
/* I included this one trying to fix the problem but it didn't went
away */
#include <linux/version.h>
#undef new
} // extern "C" //
/* init_module() and cleanup_module() followed... */
/* ===== Makefile ===== */
KIDIR=/usr/src/linux/include
KCPPFLAGS=-D__KERNEL__ -DMODULE -DLINUX -DDEBUG \
-Wall -Wstrict-prototypes -O2 \
-I$(KIDIR) \
-fno-builtin -fno-rtti -fno-exceptions
KCPP=g++
tmp_module.o: main.o cppclasses.o
$(LD) -r $^ -o $@
#LKM body
main.o: main.c
$(KCPP) $(KCPPFLAGS) -c -o $@ $+
# C++ symbols (builtin_new, ...)
symbols.o: symbols.c
$(KCPP) $(KCPPFLAGS) -c -o $@ $+
#C++ files
cppclasses.o: cppclassA.o cppclassB.o symbols.o
$(LD) -r $^ -o $@
cppclassA.o: cppclassA.c cppclassA.h
$(KCPP) $(KCPPFLAGS) -c -o $@ cppclassA.c
cppclassB.o: cppclassB.c cppclassB.h
$(KCPP) $(KCPPFLAGS) -c -o $@ cppclassB.c
Thanks in advance,
Rui Antunes
------------------------------
From: Petric Frank <[EMAIL PROTECTED]>
Subject: Re: Char device drivers and mknod
Date: Thu, 21 Dec 2000 02:49:05 +0100
Hello Kaz,
Kaz Kylheku schrieb:
>
> On Thu, 21 Dec 2000 00:56:19 +0100, Petric Frank <[EMAIL PROTECTED]> wrote:
> >Isn't there a possibility to create this device node in /dev at loading
> >time by the character device driver himself ?
>
> Yes! You need to have a kernel which supports something called devfs: a virtual
> /dev filesystem exported by the kernel, similar to /proc. It provides a
This is (if i remember correctly) not in 2.2.x kernels - only from 2.4.x
onwards. This may not be an option for me.
> solution to the problem of dynamic device numbers, as well as to the problems
> of disk space wasted by /dev hierarchies that have much more entries than
> the list of devices actually available, and the problems of access speed;
> having to hit a real filesystem just to determine what major and minor number
> to hook into.
Agree.
> >Thinking about a 'mknod' in the init_module function of the device
> >driver. Is such a thing possible ?
> >If yes, how it have to be coded ?
>
> It's possible, but there must be a reason why it's a bad idea, because you
> don't see it done. :)
Any example how to do this 'mknod' inside the device driver ?
I am interested on the reason not to do this (mknod in device drivers).
Actually i can not understand why i should not code it into the driver.
regards
Petric
------------------------------
Date: Wed, 20 Dec 2000 20:55:08 -0500
From: jtnews <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.advocacy
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!
Russ Lyttle wrote:
> Unfortunately, the correct answer is YEP. You might win, Intel might
> loose, but in the meantime, who has money to pay for lawyers? I would
> suggest contacting Intel and clearing it with them first. Otherwise post
> the code as "anonymous coward" somewhere from a cybercafe.
What I don't understand is why a company as big as Intel won't support
Linux, even if it was just a driver with an object file and no source,
that would do. I'd like to use the Easy PC camera as a home security
intrusion detection camera. If they made the driver available for
Linux, then I'd buy
at least 3 more cameras.
------------------------------
From: "Victor" <[EMAIL PROTECTED]>
Subject: Re: how to use "pthread_rwlock_t" in linux?
Date: Thu, 21 Dec 2000 11:14:13 +0800
Reply-To: "Victor" <[EMAIL PROTECTED]>
Thank you. It works.
I also found that it also works when you put definition "__USE_UNIX98"
before the
reference of <pthread.h> as codes below:
{
......
#define __USE_UNIX98
#include <pthread.h>
...
}
Here the new problem comes:
The rw_lock works when new process try to get the write_lock while another
process hold it. And the new
process will be blocked. But the new process couldn't be waked when the old
process unlock the write_lock.
I traced the program and found that the "__rw_writer" is the same as the
"__rw_write_waiting" when blocked.
I think they should be different because they are identities of 2 different
processes.
BTW, I set PTHREAD_PROCESS_SHARED of the rw_lock and put the rw_lock in the
shared memory.
But I found it make no difference whether you set PTHREAD_PROCESS_SHARED or
PTHREAD_PROCESS_PRIVATE of the attribute. Maybe this option was not
implemented by the Linux?
Regards,
Victor
"David Schwartz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Victor wrote:
> >
> > I want to use Process_shared "pthread_rwlock_t" in my program.
> >
> > But it seems that my Linux(Redhat 6.1) doesn't support it and always
report
> > compiling error "aggregate `struct pthread_rwlock_t rw_lock' has
incomplete
> > type and cannot be initialized".
> >
> > I found its definition in the "/usr/include/bits/pthreadtypes.h", but
it
> > fellows
> > a switch "__USE_UNIX98". Maybe it was not opened yet.
> >
> > How can I use it? Need I re-compile my Linux and how to open
> > "__USE_UNIX98"?
>
> Compile with -D_XOPEN_SOURCE=500
>
> DS
------------------------------
From: [EMAIL PROTECTED] (Isaac)
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Subject: Re: [OT] Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Thu, 21 Dec 2000 03:22:20 GMT
On Wed, 20 Dec 2000 16:03:45 +0100, Stefaan A Eeckels
<[EMAIL PROTECTED]> wrote:
>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 with this logic is that under some circumstances,
a candidate is legally allowed to demand a manual recount. Your
theory suggests that such a recount should never be allowed, but
if the Supreme Court's ruling is to be taken at face value, the
only thing wrong with the final recount ordered by the Florida Supreme
Court was that no state wide standard was established and that
there was no time left implement one.
To me that suggests that the machine count is a convenience that
because of the large number of votes involved, won't be challenged
as long as the error rate doesn't appear to affect the results.
But once possible errors are identified, we want an accurate count
and not one that is simply fair.
Isaac
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: how to use "pthread_rwlock_t" in linux?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Dec 2000 04:39:22 GMT
On Thu, 21 Dec 2000 11:14:13 +0800, Victor <[EMAIL PROTECTED]> wrote:
>Thank you. It works.
>
>I also found that it also works when you put definition "__USE_UNIX98"
However note that __USE_UNIX98 is not the documented public interface for doing
this. Take a look inside the /usr/include/features.h header. The __USE macros
are for internal use. If you use them directly, it might not work. For
instance, one such macro might implicitly require another one.
>BTW, I set PTHREAD_PROCESS_SHARED of the rw_lock and put the rw_lock in the
>shared memory.
Unfortunately, that is not supported by the implementation; you are out
of luck, at least for some time to come.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.advocacy
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Dec 2000 04:48:34 GMT
On Wed, 20 Dec 2000 20:55:08 -0500, jtnews <[EMAIL PROTECTED]> wrote:
>Russ Lyttle wrote:
>
>> Unfortunately, the correct answer is YEP. You might win, Intel might
>> loose, but in the meantime, who has money to pay for lawyers? I would
>> suggest contacting Intel and clearing it with them first. Otherwise post
>> the code as "anonymous coward" somewhere from a cybercafe.
>
>What I don't understand is why a company as big as Intel won't support
>Linux, even if it was just a driver with an object file and no source,
>that would do.
It is precisely because they are so big. Intel looks like one megacorporation
from the outside, but from the inside view they are a collection of many
divisions, some of them small. One division doesn't necessarily know what
another one is doing. So you cannot have some global Intel-wide Linux support
initiative. Every little project team basically has to decide whether and how
to go about it. However, what is Intel-wide is a general paranoia about
releasing information that comes down from the top. So if someone on the Easy
PC camera team wanted to release the information that would help people make a
driver, he or she would probably have to deal with quite a bit of bureaucracy.
Or maybe nobody on that team has thought of doing that. Or perhaps---you never
know---that team has Linux support already in their future product plan. Aside
from reverse engineering, the only way to get anywhere is to get in touch with
the people within Intel who developed that camera. There could be as few
as only 20-30 people behind that.
> I'd like to use the Easy PC camera as a home security
>intrusion detection camera. If they made the driver available for Linux, then
>I'd buy at least 3 more cameras.
Of course, unless the Easy PC camera people read this newsgroup, they
won't know that. ;)
------------------------------
From: "O.Petzold" <[EMAIL PROTECTED]>
Crossposted-To: linux.sources.kernel,comp.os.linux.embedded,gnu.g++.help
Subject: Re: c++ linux kernel question
Date: Thu, 21 Dec 2000 10:51:26 +0100
>
> >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().
Well, __do_global_Xtor_aux is in the .init section? of the elf format and/or it's
called by a dummy function (which is in the .init section). I'm not a OS and
Asm Guru. This functions calls/cleans the global xtors. Normally this is called
indirect before main(). So from linux kernel I have to call it by my self if I
wish to have global XTors. I agree, there are other ways. So my first intention
that is a linker symbol created by gcc is wrong.
This is what I did read from the source.
> >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?
Mostly I recompiled libgcc2.c for this with the regarded defines. If you are
interested in I could send you the dist. new/delete isn't the problem (the easiest
part of this)
> >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.
I agree with you once more. You have similar problems with modules written
in C. They have to be clean and friendly. I don't want to catch all faults which
comes from the coder - there could/should be/I'm not expecting no such
behavior as in user space. I'm happy if I can call automaticly the destructors and
remove_the_module(__this_module) in case of abort. The responsibility causes
to the programmer independent of the language C/C++ in kernel! I can only
a little bit help to make it easier. One example could be, the program calls
uncatched_exception due to a forgotten catch(...). The code is friendly to the
kernel (no other faults) and the module removes self. Other example could be
that the programmer is able to catch(std::bad_alloc) self and do the error
handling self. Nevertheless, the kernel programmer has responsibility to the
system!
_All_ what I want to have is the power of the full language C++ support, not only
if((ret = foo())< 0) { ....}
The problem relays on shared sources for user and kernel space.
> 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.
Well, same problem as in C. I know that. In worst case I have to reboot (or use
the debugger to set the counter self or use a backdoor in the program for this).
release_module seem's not to be in the kernel 2.2.x that's right ? I see only
free_module(&__this_module, 1) which can be called from kernel abort()?
With this - where comes the __this_module symbol from. It's deklared as
extern in linux/module.h but where defined ??? It occoures on use in several
kernel modules but, I can't find the definition.
> 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.
This could be the default behavior of kernel abort(). The system isn't in panic
and can't do any mistakes.
As I can see from the sources, __do_global_Xtors_aux does initialize the
frame_infos or excpetion ahndling as well but it's not worling on use of this.
I guess I have to call other functions. The problem I'm new in OS programming
and no idea about specs of elf or what going on initilaizing before main().
Who can help ?
Thanks
Olaf
------------------------------
From: "O.Petzold" <[EMAIL PROTECTED]>
Subject: Re: PANIC: C++ in Kernel Module gives strange version error!
Date: Thu, 21 Dec 2000 10:59:48 +0100
>
> However, when I insmod'ed it I got a slap in the face:
> $ insmod tmp_module.o
> tmp_module.o: couldn't find the kernel version the module was
> compiled for
>
> Why?!? (when I used no C++ code it worked fine!)
Why? - I have no idea. Two ways are possible, The first compile
one of your c++ source with included <module.h> and defined MODULE
(best would be where init/cleanup_module is) with -O0 (zero) !
The other write an empty c-file:
# more kversion.c
----8<---
/* -*- C -*- ***************************************************
* $Id: $
*
* DESCRIPTION: the module version info
*
* Copyright (C) 2000 O.Petzold <[EMAIL PROTECTED]>
*/
/** get the kernel version string */
#include <linux/module.h>
#include <linux/version.h>
---->8---
and you will get the symbols as well. Therfore you have to compile the
other
sources with the __NO_VERSION__ define.
It seems, that the g++ compiler is more hungry than the gcc. Maybee it's
related with the extern "C" statement. No idea.
Regards
Olaf
------------------------------
From: "Geoff Winkless" <[EMAIL PROTECTED]>
Subject: Re: Linix terminal emulation software
Date: Thu, 21 Dec 2000 10:05:09 -0000
"Anders Larsen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
: owl wrote:
: >
: > Where can I find Linix terminal emulation software running in MS Window
?
:
: Look for the terminal emulator "TeraTerm", it's capable of serial,
: telnet, and even ssh connections.
Easily the best windoze telnet/ssh client I've found is putty -
http://www.chiark.greenend.org.uk/~sgtatham/putty/
It's even Open Source. :)
Geoff
------------------------------
From: [EMAIL PROTECTED] (Erik Hensema)
Subject: Re: ip_masq_ftp.c
Date: Thu, 21 Dec 2000 10:54:46 +0100
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
>I've recently found a (very) small bug in the IP MASQ FTP module, and
>I've already gone ahead and changed the code on my machine to fix it.
>However, I cannot find out who to send this information to so it can
>be worked into the kernel!
When in doubt, just email the mail Linux Kernel Mailing List.
--
Erik Hensema ([EMAIL PROTECTED])
Registered Linux user #38371 -- http://counter.li.org
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Subject: Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Wed, 20 Dec 2000 20:42:57 +0100
In comp.os.linux.development.system Jeffrey B. Siegal <[EMAIL PROTECTED]> wrote:
> Fergus Henderson 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
It measures it. You can build a statistical model and construct an
estimator for the mean and standard deviation from this information.
> machine is working properly overall. (It might be double counting other
> ballots, which would partially cancel the effect of uncounted ballots,
> for example.)
So what? That's taken account of in the model you'd use to get the
estimator. If you have any experiment (like this) and any model (i.e.
mean error and standard deviation for the machines behaviour overall)
and observations (running the ballots and counting and examining
rejects) you can make up formulas for estimators of the error
distribution from the observatuons, and then you can go ahead and
derive formulas for the bias and/or error deviation in the estimator.
If the expected bias of your formula is zero, and its standard
deviation is low, then its a good estimator.
Stats class, please. For example, everyone knows that to estimate
the standard deviation of the distro underlying a set of observations,
you have to use the sum of the squares divided by n-1, not n, because
dividing by n gives you a biased estimator. But the estimator is simply
a formula that takes the obsrevations and calculates a parameter.
Peter
------------------------------
** 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
******************************
