Linux-Development-Sys Digest #310, Volume #8     Wed, 29 Nov 00 14:13:21 EST

Contents:
  Module Compilation Problems (Rand Simberg)
  Re: Module Compilation Problems (Arne Driescher)
  Re: Module Compilation Problems (Rand Simberg)
  Re: Module Compilation Problems (Anders Larsen)
  Re: floating point in kernel... (Nick Maclaren)
  Re: Module Compilation Problems (Rand Simberg)
  kernel panic: VFS unable to mount root (--i've tried using rdev--) (Bart De Schuymer)
  Re: gcc-2.95.2 forces ALL c++ programs to be GPL !!??!# (Philip Armstrong)
  Re: Kernel preemption - socket handling (Philip Armstrong)
  Chaing the name of a linux process ("news.chello.nl")
  Re: Does filesystem fragment? (Erik Hensema)
  Re: gcc-2.95.2 forces ALL c++ programs to be GPL !!??!# ([EMAIL PROTECTED])
  Re: Kernel preemption - socket handling (Kaz Kylheku)
  Why PostgreSQL is not that popular as MySQL? (Raymond Chui)
  global concepts on task_struct, thread_struct (Snoopy)

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

From: [EMAIL PROTECTED] (Rand Simberg)
Subject: Module Compilation Problems
Date: Wed, 29 Nov 2000 15:09:32 GMT

I recently upgraded to RH 7.0 from 6.2.  I was running the 2.2.13
kernel.  I have a Unicom NIC, for which I had compiled the module that
came with the card under 2.2.13.  After the upgrade to RH7.0, I
decided to also upgrade my kernel, as I wanted to set up the machine
as a server with the latest security features.  RH told me that I
might have problems with 2.2.17, so I did 2.2.16.  

After uninstalling the 2.4 kernel headers provided by RH and the
kernel rebuild (which involved hacking the Makefile to use kgcc,
rather than the gcc 2.96 that RH provided), it seems to work all
right.  

Except that when I try to insmod the driver (named winbond-840.o) for
the NIC, it tells me that it's compiled for the wrong kernel.  When I
try to recompile it under 2.2.16 using kgcc, using the following
command:

kgcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall
-Wstrict-prototypes -O6 -c winbond-840.c `[ -f
/usr/include/linux/modversions.h ] && echo -DMODVERSIONS`

I get the following error messages:

In file included from winbond-840.c:63:
/usr/i386-glibc21-linux/include/linux/config.h:4: linux/autoconf.h: No
such file or directory
winbond-840.c:64: linux/version.h: No such file or directory
In file included from winbond-840.c:69:
/usr/i386-glibc21-linux/include/linux/module.h:203: linux/version.h:
No such file or directory
In file included from winbond-840.c:127:
/usr/i386-glibc21-linux/include/linux/bios32.h:11: warning: #warning
This driver uses the old PCI interface, please fix it (see
Documentation/pci.txt)
winbond-840.c:1057: macro `dev_kfree_skb' used with too many (2) args
winbond-840.c:1380: macro `dev_kfree_skb' used with too many (2) args
winbond-840.c:1386: macro `dev_kfree_skb' used with too many (2) args


What did I screw up?


************************************************************************
simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)  
interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org 

"Extraordinary launch vehicles require extraordinary markets..."
Replace first . with @ and throw out the "@trash." to email me.  
Here's my email address for autospammers: [EMAIL PROTECTED]

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

From: Arne Driescher <[EMAIL PROTECTED]>
Subject: Re: Module Compilation Problems
Date: Wed, 29 Nov 2000 17:35:20 +0100

> 
> kgcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall
> -Wstrict-prototypes -O6 -c winbond-840.c `[ -f
> /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`
> What did I screw up?

An other guess today .....

Try to change
-I/usr/src/linux/net/inet
into 
-I/usr/src/linux/include
or append it to the already used search path in case the first one
is really necessary e.g.
kgcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet
-I/usr/src/linux/include ......

-Arne

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

From: [EMAIL PROTECTED] (Rand Simberg)
Subject: Re: Module Compilation Problems
Date: Wed, 29 Nov 2000 16:49:08 GMT

On Wed, 29 Nov 2000 17:35:20 +0100, in a place far, far away, Arne
Driescher <[EMAIL PROTECTED]> made the phosphor on
my monitor glow in such a way as to indicate that:

>> 
>> kgcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall
>> -Wstrict-prototypes -O6 -c winbond-840.c `[ -f
>> /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`
>> What did I screw up?
>
>An other guess today .....
>
>Try to change
>-I/usr/src/linux/net/inet
>into 
>-I/usr/src/linux/include
>or append it to the already used search path in case the first one
>is really necessary e.g.
>kgcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet
>-I/usr/src/linux/include ......

That did it!  (Though I don't know yet if it works, but at least it
compiled...)

Thanx...

What changed that required me to do that, when I didn't have to do it
before (i.e., when I compiled it under 2.2.13 with gcc)?

************************************************************************
simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)  
interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org 

"Extraordinary launch vehicles require extraordinary markets..."
Replace first . with @ and throw out the "@trash." to email me.  
Here's my email address for autospammers: [EMAIL PROTECTED]

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

From: Anders Larsen <[EMAIL PROTECTED]>
Subject: Re: Module Compilation Problems
Date: Wed, 29 Nov 2000 17:25:17 +0100

Rand Simberg wrote:
[snip]
> When I
> try to recompile it under 2.2.16 using kgcc, using the following
> command:
> 
> kgcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall
> -Wstrict-prototypes -O6 -c winbond-840.c `[ -f
> /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`
> 
> I get the following error messages:
> 
> In file included from winbond-840.c:63:
> /usr/i386-glibc21-linux/include/linux/config.h:4: linux/autoconf.h: No
> such file or directory
> winbond-840.c:64: linux/version.h: No such file or directory
> In file included from winbond-840.c:69:
> /usr/i386-glibc21-linux/include/linux/module.h:203: linux/version.h:
> No such file or directory
> In file included from winbond-840.c:127:
> /usr/i386-glibc21-linux/include/linux/bios32.h:11: warning: #warning
> This driver uses the old PCI interface, please fix it (see
> Documentation/pci.txt)
> winbond-840.c:1057: macro `dev_kfree_skb' used with too many (2) args
> winbond-840.c:1380: macro `dev_kfree_skb' used with too many (2) args
> winbond-840.c:1386: macro `dev_kfree_skb' used with too many (2) args
> 
> What did I screw up?

You appear to have forgotten the Most Important Include Path(tm)
Just add
  -I/usr/src/linux/include
to the kgcc command line.

-- 
Anders Larsen

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

From: [EMAIL PROTECTED] (Nick Maclaren)
Subject: Re: floating point in kernel...
Date: 29 Nov 2000 17:13:23 GMT

In article <Hr8V5.62054$[EMAIL PROTECTED]>,
 <[EMAIL PROTECTED]> wrote:
>Perego Paolo <[EMAIL PROTECTED]> writes:
>> Hi guys, I know that I can't use floating point in my kernel module but
>> I need to calculate a thing like system load.
>> I've got the number of packets proccessed by my module end the number
>> of seconds my module's up ( I've used jiffies and jiffies_to_timespec )
>> ; now I need to perform (number of packets/time) to have a sort of
>> module load.
>> 
>> My problem is that I can't achieve a floating point in any manner, so
>> can you give same ideas.
>
>The problem with FP is that FP operations need to have some equivalent
>to libm in order to implement them, but libm lives in user space, not
>in kernel space.  That _is_ a necessary constraint; Linux runs on
>processors that don't have FP, thus meaning that making FP a kernel
>dependancy would be a Bad Thing.

I wouldn't say that it is a NECESSARY constraint, as there are
plenty of kernel modules (note modules, not the core) that are
dependent on hardware being available.  And it is definitely not
the case that libm is needed for floating-point support, any
more than libc is needed for fixed-point support.

That being said, there are a lot of floating-point facilities
that ARE provided by libm and, worse, the handling of many
boundary cases is done by trapping the interrupts.  While it is
possible to avoid both of those, you need to know a hell of a
lot about floating-point and your C implementation to do it
reliably.

>Perhaps you want to use fixed point math instead?  You'd have to shift
>the decimal point yourself, for display purposes, not that the decimal
>point would actually be particularly _meaningful_...

Getting this right isn't a lot easier than avoiding both libm
and the boundary cases, but it is probably a better solution in
this case.  If nothing else, it uses facilities that the average
kernel hacker will be more familiar with than floating-point :-)


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  [EMAIL PROTECTED]
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

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

From: [EMAIL PROTECTED] (Rand Simberg)
Subject: Re: Module Compilation Problems
Date: Wed, 29 Nov 2000 17:20:03 GMT

On Wed, 29 Nov 2000 17:25:17 +0100, in a place far, far away, Anders
Larsen <[EMAIL PROTECTED]> made the phosphor on my monitor glow in
such a way as to indicate that:

>You appear to have forgotten the Most Important Include Path(tm)
>Just add
>  -I/usr/src/linux/include
>to the kgcc command line.

Yes, I did that, at the suggestion of another poster, and it worked.
My question now is, why did it formerly work without that path?  That
command is the one in the source itself, and I've always used it
successfully in the past.  Is it a kgcc thing?


************************************************************************
simberg.interglobal.org  * 310 372-7963 (CA) 307 739-1296 (Jackson Hole)  
interglobal space lines  * 307 733-1715 (Fax) http://www.interglobal.org 

"Extraordinary launch vehicles require extraordinary markets..."
Replace first . with @ and throw out the "@trash." to email me.  
Here's my email address for autospammers: [EMAIL PROTECTED]

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

From: [EMAIL PROTECTED] (Bart De Schuymer)
Subject: kernel panic: VFS unable to mount root (--i've tried using rdev--)
Date: Wed, 29 Nov 2000 17:40:34 GMT

I use redhat 7.0
I compiled Linux v2.4 test7

This is the full panic:
VFS: cannot open root device "806" or 08:06
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 08:06

This is what I've tried:
Finding out the root partition of my Redhat 7.0 standard kernel:
rdev
--> /dev/sda6 /
(behind the 6 is a space and a slash, don't know why, but I thought
I'd just add it to be complete)

Then I looked at /etc/lilo.conf to be sure about the bootimage for the
recompiled kernel: /boot/bzImage2. Also it says here root=/dev/sda6
for the entry of bzImage2.

rdev /boot/bzImage2 /dev/sda6
(didn't append the space and slash)

lilo

shutdown -r now

I even tried typing root=/dev/sda6 at the lilo prompt.

I didn't copy anything to my /boot directory except the bzImage (in
/asm/i386/boot/) after compiling the kernel.
Maybe I need to copy other files too (allthough the file README didn't
tell me)?
I don't believe I forgot to compile scsi support or anything else
necessary to be able to read the partition. But if you say I have, I'm
willing to believe it ;-)


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

From: [EMAIL PROTECTED] (Philip Armstrong)
Subject: Re: gcc-2.95.2 forces ALL c++ programs to be GPL !!??!#
Date: 29 Nov 2000 09:52:07 -0000

In article <[EMAIL PROTECTED]>,
Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:
>In article <9007fu$ijo$[EMAIL PROTECTED]>,
>       [EMAIL PROTECTED] writes:
>> The bottom line is that since C++ programs statically link in
>> libstdc++.a and the libstdc++.a library includes 2 files (./gcc-
>> 2.95.2/include/ansidecl.h and ./gcc-2.95.2/texinfo/lib/strerror.c)
>> that fall under GPL (not LGPL or special exceptions), therefore these
>> files must either be removed or the rest of the executable's source
>> must be made freely available to the public.  This would seem to apply
>> to all C++ programs compiled with gcc-2.95.2.
>
>My C++ programs don't link statically to libstdc++. I'm puzzled
>as to why you and your informants seem to believe this library
>needs to be linked statically.

If you even link dynamically to a GPLd piece of code then you're
affected by the GPL. Thats why the LGPL exists.

Phil

-- 
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt


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

From: [EMAIL PROTECTED] (Philip Armstrong)
Crossposted-To: comp.os.linux.questions,alt.os.linux
Subject: Re: Kernel preemption - socket handling
Date: 29 Nov 2000 09:55:50 -0000

In article <[EMAIL PROTECTED]>,
Rui Antunes <[EMAIL PROTECTED]> wrote:
>I'm developping a (RH7) kernel module that intercepts the socket API
>and handles sockets. I have some doubts about kernel preemption and
>the (kernel) sockets. 
>
>I got this from a paper:
>
>�The Linux kernel is monolithic. Only one thread of control created by
>a system call is active at any time. This means that device drivers do
>not need to lock their data structures as a general rule.�
>
>'Only one thread of control is active at any time' or �Only one thread
>of control created by a system call is active at any time�?!?
>If my kernel module is running is it possible that other kernel may
>run (I know that software and hardware interrupts can)?

Sounds horribly out of date to me. In 2.0 the kernel had a single lock
which was taken on entry to a system call, hence only one system call
would be running in the kernel at any time, together with any
interrupt handlers that were triggered. This is no longer the case in
2.(2|4); you have to protect critical regions of your code with
mutexes of some description in order to prevent race errors occuring.

>If my kernel module handles (modifies) sockets is it necessary to use
>some kind of kernel-locking mechanism to avoid race conditions
>(regarding kernel functions that implement transport and network
>layers)?

Almost certainly. Read up on the locking documentation in
/usr/src/linux/Documentation (or wherever you keep your kernel
sources).

Phil


-- 
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt


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

From: "news.chello.nl" <[EMAIL PROTECTED]>
Subject: Chaing the name of a linux process
Date: Wed, 29 Nov 2000 19:24:39 +0100

Hi,

Can anyone tell me whether its possible for a process to customise the name
that appears for it when you do a 'ps' command?

I thought it might be, because the sendmail process seems to customise
itself
such that you get 'sendmail: accepting connections on port 25' appear.

Jason.



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

From: [EMAIL PROTECTED] (Erik Hensema)
Subject: Re: Does filesystem fragment?
Date: Wed, 29 Nov 2000 16:09:43 +0100
Reply-To: [EMAIL PROTECTED]

Al Byers ([EMAIL PROTECTED]) wrote:
>I am looking to build an intermediate storage system for temporarily
>storing variable length XML strings that come from multiple sources. I
>originally did it using the MySQL database, but the insertion was very
>slow due to multiple keys and inefficient programming. I could work
>on that aspect, but the thought occurred that simple flat files will
>give me what I want - sequential storage and access, keyed by one value
>(the file name), easy to maintain (use "find" to remove dead files). My
>concern is that with all the creating and destroying of files, that the
>filesystem will get hopelessly fragmented. I am running Redhat 6.2. Is
>that a valid concern? Are there steps that I can take to deal with it?

No, that's not a valid concern.

-- 
Erik Hensema ([EMAIL PROTECTED])
This signature is generated by siggen.pl v0.1
Available soon at http://www.xs4all.nl/~hensema

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

From: [EMAIL PROTECTED]
Subject: Re: gcc-2.95.2 forces ALL c++ programs to be GPL !!??!#
Date: Wed, 29 Nov 2000 18:26:39 GMT

Philip Armstrong <[EMAIL PROTECTED]> wrote:
> If you even link dynamically to a GPLd piece of code then you're
> affected by the GPL. Thats why the LGPL exists.

No. The LGPL exists almost entirely because of bison, which was the
main bone of contention years ago. (Even prior to C++ ;)

The problem is that bison, like yacc, includes a substantial amount of
source code in the form of a stock parser to whatever parser it
generates. In fact, it's not unusual for the included program
statements to actually outnumber those provided by the user.

The fact that the same problems are creeping up again is just a sign
that the GPL has lived past its time. None of the concerns it was
built to address really remain today, nor are they likely to
resurface.

As to arguing which license linking applies too, that's an academic
exercise at best. It's never been tested in court, nor is it likely to
be. Most arguments seem to center around the opinion of the FSF's
lawyers, which is somewhat unimpressive. It's not difficult to find a
lawyer to argue any position.

-- 
Matt Gauthier <[EMAIL PROTECTED]>

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

From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.questions,alt.os.linux
Subject: Re: Kernel preemption - socket handling
Reply-To: [EMAIL PROTECTED]
Date: Wed, 29 Nov 2000 18:38:13 GMT

On Tue, 28 Nov 2000 23:27:20 GMT, Rui Antunes <[EMAIL PROTECTED]> wrote:
>I'm developping a (RH7) kernel module that intercepts the socket API
>and handles sockets. I have some doubts about kernel preemption and
>the (kernel) sockets. 
>
>I got this from a paper:
>
>�The Linux kernel is monolithic. Only one thread of control created by
>a system call is active at any time. This means that device drivers do
>not need to lock their data structures as a general rule.�

That was never true because of interrupts.  It's dated information anyway
because under 2.1 kernels and higher, the kernel can be executed concurrently
by multiple processors.  If you do not lock the structures, the driver may work
on a single processor machine, but when compiled for SMP, it will have race
conditions.

>'Only one thread of control is active at any time' or �Only one thread
>of control created by a system call is active at any time�?!?

That is true of any operating system on a single processor. The issue is when a
thread can be preempted so that another thread can be assigned to the
processor. In Linux, a thread that is executing kernel code cannot be
preempted---another thread can get the processor only if an explicit call to
the scheduler is made. Under multiple processors this is true from the point of
view of any individual processor; a thread won't be involuntarily taken off
its processor while executing kernel code, but other threads can execute in
parallel on other processors.

There has been talk of introducing interruptibility to the kernel, under the
rationale that if the kernel works under the true concurrency of SMP, why not
allow virtual concurrency as well?  That is to say, code which is outside of
any lock should, in principle, work correctly if it is preempted to run another
thread on the same processor, because it already works correctly with threads
that are locked to their respective processors.

>What kernel-locking mechanisms are available?

Spinlocks. Read Documentation/spinlocks.txt

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

From: Raymond Chui <[EMAIL PROTECTED]>
Crossposted-To: 
comp.databases.postgresql.general,comp.databases.postgresql.committers,comp.os.linux.misc
Subject: Why PostgreSQL is not that popular as MySQL?
Date: Wed, 29 Nov 2000 13:55:43 -0500

This is a multi-part message in MIME format.
==============D3FEBAC53F861466FAFA6C59
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I am just start look at PostgreSQL for our Redhat Linux.
I am wonder why most of people choose MySQL in Linux
world rather than PostgreSQL? PostgreSQL has 15 years
history (I never know that before) which is much longer
than MySQL. Also PostgreSQL supports a lot of things
which MySQL has not support yet.


--
Why we want to teach our babies to talk and walk,
then later we tell them "sit down!", "be quiet!" ?

Democracy is not a better way for a solution,
it is just another way to spread the blames.


==============D3FEBAC53F861466FAFA6C59
Content-Type: text/x-vcard; charset=us-ascii;
 name="raymond.chui.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Raymond Chui
Content-Disposition: attachment;
 filename="raymond.chui.vcf"

begin:vcard 
n:Chui;Raymond
tel;fax:(301)713-0963
tel;home:ICQ #: 16722494
tel;work:(301)713-0624 Ext. 168
x-mozilla-html:TRUE
url:http://members.xoom.com/rchui/
org:NWS, NOAA
version:2.1
email;internet:[EMAIL PROTECTED]
title:SA, DBA
adr;quoted-printable:;;NOAA, NWS, Office of Hydrology, W/OH2=0D=0A1325 East-West 
Highway, Room 8112;Silver Spring;MD;20910-3283;U.S.A.
x-mozilla-cpt:;30256
fn:Raymond Chui
end:vcard

==============D3FEBAC53F861466FAFA6C59==


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

From: Snoopy <[EMAIL PROTECTED]>
Subject: global concepts on task_struct, thread_struct
Date: Wed, 29 Nov 2000 12:03:26 -0700

Hello everyone:
    Hope that this email is in the right place.

    Recently, I read a book about Linux kernel and it discussed one
structure task_struct and when I read the source code, I found another
structure thread_struct.  After reading codes, it seems to me that
thread_struct is used when a context-switch is performed, but why
scheduler check the STATUS of a task_struct?  What's the difference
between task_struct and thread_struct?  And, what are the definitions of
THREAD, PROCESS, TASK in Linux view?


Thanks

STC


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


** 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 (and comp.os.linux.development.system) via:

    Internet: [EMAIL PROTECTED]

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
******************************

Reply via email to