Linux-Development-Sys Digest #32, Volume #8 Wed, 19 Jul 00 14:13:10 EDT
Contents:
How to handle paths (Jim Thomas)
Re: floating point issue (Grant Edwards)
Re: Interrupt handling in Linux (Marco van de Voort)
Re: floating point issue (Robert Cox)
Q: writing to a file in the kernel (Pau-Chen Cheng)
Q: writing to a file in the kernel (Pau-Chen Cheng)
Semaphores in the kernel (Wayne Rasmuss)
Re: floating point issue (Mathias Waack)
(Q) Capturing everything at boot time (Timothy Murphy)
How to force a clean reboot from a module? ("Norm Dresner")
Re: Semaphores in the kernel (Mathias Waack)
PAM - clue me in please (Tony Scholes)
Still no NFS in 2.2.16 ([EMAIL PROTECTED])
Re: floating point issue (Grant Edwards)
Re: C problem (Kaz Kylheku)
Re: floating point issue ([EMAIL PROTECTED])
Re: C problem (Kaz Kylheku)
Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC (bill davidsen)
Re: structure casting w/ (void *) (c++) ([EMAIL PROTECTED])
Re: floating point issue ("Christos D. Antonopoulos")
Resources for writing device drivers (MJ Dainty)
----------------------------------------------------------------------------
From: Jim Thomas <[EMAIL PROTECTED]>
Subject: How to handle paths
Date: Wed, 19 Jul 2000 09:46:06 -0400
I've just received some code originally written for Windoze. My mission
is to compile it for Linux. One of the first problems I've encountered
is how to handle the directory path delimiter so that it compiles for
both:
#include "dir\file.h"
^ this is bad for *nix.
My first thought was to encapsulate these includes in an #if clause:
#if (something)
#include "dir\file.h"
#else
#include "dir/file.h"
#endif
but that is ugly, and I'm not sure what #if I should key on. There has
to be an elegant way to handle this problem, as thousands of engineers
must have seen it before. Any hints?
--
Jim Thomas E-mail: [EMAIL PROTECTED]
Senior Applications Engineer Web: http://www.bittware.com
Bittware, Inc Tel: (703) 779-7770
I thought I was wrong once, but I was mistaken.
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: floating point issue
Date: Wed, 19 Jul 2000 14:24:25 GMT
In article <[EMAIL PROTECTED]>, Erik Max Francis wrote:
>Grant Edwards wrote:
>
>> [EMAIL PROTECTED] wrote:
>>
>> >But, it said "main.o: unresolved symbol log"
>> >
>> >I need to do floating point calculation (like log(), pow(), sqrt(),
>> >etc) in my driver, but how can I achieve it?
>>
>> The short answer is you can't.
>
>The long answer is that you'll probably have to write your own
>approximators. Any good maths-oriented computer science text will have
>these.
No. The problem isn't that the library routines aren't
availabled. The problem is that you aren't allowed to do
floating point calculations in kernel routines. The kernel
design doesn't allow for it.
My understanding is that a user-process floating point context
isn't saved until it has to be, and doing floating point in a
kernel module will break this scheme.
--
Grant Edwards grante Yow! I know things about
at TROY DONAHUE that can't
visi.com even be PRINTED!!
------------------------------
From: [EMAIL PROTECTED] (Marco van de Voort)
Subject: Re: Interrupt handling in Linux
Date: 19 Jul 2000 14:26:30 GMT
> * multiple processes
> * poll()/select() [I forget which one is in fashion these days].
Afaik Select is for synchronous IO, while the originator of the thread wants
to async?
Which means he has to install a signalhandler for SIGIO using signal or
sigaction, a method not even that far from a interrupt handler.
I'm currently wrestling with this too, trying to port a non-GUI Delphi
application to Linux/BSD
------------------------------
From: [EMAIL PROTECTED] (Robert Cox)
Subject: Re: floating point issue
Date: 19 Jul 2000 14:37:00 GMT
Grant Edwards ([EMAIL PROTECTED]) wrote:
: My understanding is that a user-process floating point context
: isn't saved until it has to be, and doing floating point in a
: kernel module will break this scheme.
So why can't a driver manually save/restore the floating point
context itself?
bobcox
------------------------------
From: Pau-Chen Cheng <[EMAIL PROTECTED]>
Subject: Q: writing to a file in the kernel
Date: Wed, 19 Jul 2000 10:48:22 -0400
Hi, I need to write some data in a kernel buffer to a file.
I can open a file in the kernel for write and I would like
to use the VFS interface to write the data to the file.
So far I have failed to write to a file on an ext2 file system.
the write operation in the VFS seems to require the data
be in a user-space buffer.
Could any one help me ?
Thanks in adavnce.
Pau-Chen
------------------------------
From: Pau-Chen Cheng <[EMAIL PROTECTED]>
Subject: Q: writing to a file in the kernel
Date: Wed, 19 Jul 2000 10:50:13 -0400
Hi, I need to write some data in a kernel buffer to a file.
I can open a file in the kernel for write and I would like
to use the VFS interface to write the data to the file.
So far I have failed to write to a file on an ext2 file system.
the write operation in the VFS seems to require the data
be in a user-space buffer.
Could any one help me ?
Thanks in adavnce.
Pau-Chen
------------------------------
From: Wayne Rasmuss <[EMAIL PROTECTED]>
Subject: Semaphores in the kernel
Date: Wed, 19 Jul 2000 10:00:31 -0500
I am creating an extension to the linux-2.2.9 kernel that deals with
forwarding packets received via an eithernet interface. I use ioctl
functions to change routing information. I need to protect my data
against collisions between ioctl calls from different applications. or
one application and the kernel. Does anyone know the correct way to do
this?
Thanks For Your Help
Wayne
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: floating point issue
Date: 19 Jul 2000 16:50:21 +0200
[EMAIL PROTECTED] (Robert Cox) writes:
> Grant Edwards ([EMAIL PROTECTED]) wrote:
> : My understanding is that a user-process floating point context isn't
> :saved until it has to be, and doing floating point in a kernel module
> :will break this scheme.
>
> So why can't a driver manually save/restore the floating point context
> itself?
It can. Nobody forbids you doing floating point calculation inside the
kernel. The kernel sources are free. Do what you want with it.
But adding floating point support to kernel would add a lot of code and
slow down the whole kernel. So the kernel will (probably) never support
floating point. And there is not need for this. I've never seen a
situation where somebody really(!) needs floating point in a driver.
Do this stuff in the user space and avoid a lot of problems.
Mathias
------------------------------
From: [EMAIL PROTECTED] (Timothy Murphy)
Subject: (Q) Capturing everything at boot time
Date: 19 Jul 2000 16:26:52 +0100
dmesg doesn't capture everything that flashes by at boot-time,
eg inconsistencies between modules.
Is there any simple way -- a kind of kernel "script" --
which will save everything that appears on the screen at boot-up?
--
Timothy Murphy
e-mail: [EMAIL PROTECTED]
tel: 086-233 6090
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
------------------------------
Reply-To: "Norm Dresner" <[EMAIL PROTECTED]>
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: How to force a clean reboot from a module?
Date: Wed, 19 Jul 2000 15:39:52 GMT
I'm in the middle of developing a device driver/module for a board and I
occasionally run into situations in which the driver knows that its data
structures are fouled up and (probably) can't be removed with rmmod -f.
Is there some way for a driver to force a safe/clean reboot which includes
the normal sync-mechanism and unmounting of file systems?
Thanks
Norm
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: Semaphores in the kernel
Date: 19 Jul 2000 17:28:22 +0200
Wayne Rasmuss <[EMAIL PROTECTED]> writes:
> I am creating an extension to the linux-2.2.9 kernel that deals
> with forwarding packets received via an eithernet interface. I use
> ioctl functions to change routing information. I need to protect my
> data against collisions between ioctl calls from different
> applications. or one application and the kernel. Does anyone know the
> correct way to do this?
One way would be to use spinlocks, look in /usr/src/linux/Documentation/spinlocks.txt
for more informations.
Mathias
------------------------------
From: Tony Scholes <[EMAIL PROTECTED]>
Subject: PAM - clue me in please
Date: Wed, 19 Jul 2000 18:07:16 +0200
Hi
System: RH 6.X (but I need to be Linux distro and O/S independant)
I'm developiong an application that needs to autenticate a user against
the standard /etc/passwd & /etc/shadow tables and I'm looking to use PAM
to do it.
I've got some working code from the examples, but want to have the app
*silently* authenticate. It will have the user name and the clear text
password, all I want is for it to call the appro. PAM fucntions and be
told either yes or no in the return code. I do not want the PAM
authentication modules to prompt for passwords etc. Which is all I can
get going at the mo.
I am using a PAM config file (in /etc/pam.d) which uses either the
pam.unix.auth.so or pam_pwdb.so modules to authenticate (both work OK).
How do I get what I want? Do I have to use the conversation function
capability? Or can I set a PAM Item to the clear text password? Do I
(heavan forfend!) have to write a PAM module that does this?
TIA
--
Tony Scholes
------------------------------
From: [EMAIL PROTECTED]
Subject: Still no NFS in 2.2.16
Date: 19 Jul 2000 16:06:24 GMT
Never got a reply to my previous post; why doesn't knfsd work in 2.2.16 (at
least on Linux)? I always get an error with "nfssvc".
It seems to work fine with kernel 2.2.12, which I'm currently using. I built
both kernels from source, using the same nfs options.
I'd very much appreciate any pointers to info on this problem.
Hugh
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: floating point issue
Date: Wed, 19 Jul 2000 16:31:39 GMT
In article <[EMAIL PROTECTED]>, Mathias Waack
wrote:
>[EMAIL PROTECTED] (Robert Cox) writes:
>
>> Grant Edwards ([EMAIL PROTECTED]) wrote:
>> : My understanding is that a user-process floating point context isn't
>> :saved until it has to be, and doing floating point in a kernel module
>> :will break this scheme.
>>
>> So why can't a driver manually save/restore the floating point context
>> itself?
>
>It can. Nobody forbids you doing floating point calculation inside the
>kernel. The kernel sources are free. Do what you want with it.
>
>But adding floating point support to kernel would add a lot of code and
>slow down the whole kernel. So the kernel will (probably) never support
>floating point. And there is not need for this. I've never seen a
>situation where somebody really(!) needs floating point in a driver.
>Do this stuff in the user space and avoid a lot of problems.
In addition to the performance hit, there are other problems
with having a driver save/restore floating point context so it
can do floating point operations:
1) You're binding your driver to one a single CPU architecture.
You may even have to handle different versions of that CPU
individually.
2) Your scheme will probably end up being very fragile with
respect to kernel changes.
3) You're going to have to write all your own floating point
support routines (possibly even the "invisible" ones in
libgcc) and you've got to do it while living within the
restrictions of kernel space.
4) You're going to have to be _really_ careful about
FP exceptions.
5) You'll need to carefully examine the FP code generated
by gcc to make sure it's not doing anything 'bad' from
a kernel perspective.
None of these are insurmountable problems. But, in the past,
the people who've wanted to do floating point in drivers
(myself included) have decided it wasn't worth the effort.
Your case may be different. I can think of some problem
domains (e.g. continuous process control) where FP calculations
and values are such fundamental things that one would expect
device drivers to be FP capable. Since vanilla Linux tends not
be used for things like that, it hasn't been done.
--
Grant Edwards grante Yow! This is my WILLIAM
at BENDIX memorial CORNER
visi.com where I worship William
Bendix like a GOD!!
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: C problem
Reply-To: [EMAIL PROTECTED]
Date: Wed, 19 Jul 2000 17:05:41 GMT
On Wed, 19 Jul 2000 17:49:35 +0800, Eric Co <[EMAIL PROTECTED]> wrote:
>hi,
>in the follow example, when it call strtok, it will got segmentation fault
>in Linux,
>but with the same code, it won't happen in win32, what is the problem?
You should post elementary C programming questions to a C programming
newsgroup like comp.lang.c.
>i got to use strcpy or strdup to eliminate this prolem.
>
>int main(void){
> char *str = "abc";
> char *brkstr = ",";
> char *s;
>
> s = strtok(str, brkstr);
The problem is that strtok is destructive; it writes to the string
that is referenced by the left operand.
In this case, that string is a string literal object.
According to ANSI/ISO C, attempts to modify string literals result in undefined
behavior. GCC takes advantage of this by storing string literals in
read-only pages on architectures and platforms where this is possible.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: floating point issue
Date: Wed, 19 Jul 2000 17:01:26 GMT
In article <[EMAIL PROTECTED]>,
"Christos D. Antonopoulos" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Hi there,
> >
> > Is that possible to have floating point caculation in the driver
> > module?
>
> It is impossible to do fp math at kernel-level. It has to do with the
> way fp registers are handled during context switches. Try to do your
fp
> math with a user-level program.
>
> Christos Antonopoulos
>
Thanks for the answer from all of you.
But, I found that how come if I put the option -O2, I can load the
module (no unresolved symbol log) and I also got the correct answer!?
Does this means I CAN execute floating point calculation in the kernel
module. My Linux version is RedHat 2.2.14-12, and the /proc/cpuinfo
says
vendor_id: GenuineIntel
model name: Pentium II (Klamath)
fpu : yes
fpu_exception : yes
ps. I didn't do any fp status/registers save/store mechanism during my
fp calculation.
Anything's wrong or right?
Thanks!
-- Sam
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: C problem
Reply-To: [EMAIL PROTECTED]
Date: Wed, 19 Jul 2000 17:08:06 GMT
On Wed, 19 Jul 2000 03:46:30 -0700, China Blue Ribbon Commission
<[EMAIL PROTECTED]> wrote:
>I believe strtok tries to modify the string in place to keep its context
>between calls.
The context is maintained elsewhere. Modifying the string is part of the actual
work semantics of the function; it has to chop the string into smaller strings
in-place, which requires storing zeros into it.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.powerpc
Subject: Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC
Date: 19 Jul 2000 17:24:30 GMT
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
| But why should they limit themselves to several distributions while
| leaving out a couple of the major and important ones?
If I were picking distributions, I'd pick RedHat, Slackware, Debian,
and SuSE. Distributions Caldera, Corel, StormLinux, TurboLinux, and
Mandrake all have roots to one of the above, and that maximizes the
chances that an application will run on any Linux.
Note that they are not picked for market share, but rather for what
small differences they do exhibit. I suspect that Debian and Slackware
are more popular with developers than end users, because they do a
little less for you by default.
That's my read, in practice we hit Slackware and RedHat, both Intel
and SPARC, and only in rare cases try SuSE or Debian because we don't
run them in house on production machines.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
There are those who make things happen, those who watch things happen,
and those who wonder what happened.
-- idea from _Pickles_
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development
Subject: Re: structure casting w/ (void *) (c++)
Reply-To: [EMAIL PROTECTED]
Date: 20 Jul 2000 01:22:46 +1000
Bhavin Shah <[EMAIL PROTECTED]> writes:
>str *s1;
>f1((char *)s1);
In addition to the pevious poster's "you gotta initialise an object
before you use it", let me say that you also need to *have* an object.
str* s1; will not, repeat NOT, allocate an object of type str, but rather
a pointer to such an object. Unless you somehow create an actual object
and make s1 point at it, such a pointer will be utterly useless.
Bernie
P.S.: I have seen this problem quite frequently in some linux groups
recently. Yet I don't seem to see it much if at all in teaching
first year CS students C. Might have to do with me stressing the
differences quite a lot --- but how *is* this stuff taught at US
universities?
--
Older man declare war. But it is youth who must fight and die
Herbert Hoover
US President 1929-33
At the Republican National Convention, 27 June 1944
------------------------------
From: "Christos D. Antonopoulos" <[EMAIL PROTECTED]>
Subject: Re: floating point issue
Date: Wed, 19 Jul 2000 20:45:41 +0300
> Thanks for the answer from all of you.
> But, I found that how come if I put the option -O2, I can load the
> module (no unresolved symbol log) and I also got the correct answer!?
>
> Does this means I CAN execute floating point calculation in the kernel
> module. My Linux version is RedHat 2.2.14-12, and the /proc/cpuinfo
> says
>
> vendor_id: GenuineIntel
> model name: Pentium II (Klamath)
> fpu : yes
> fpu_exception : yes
>
> ps. I didn't do any fp status/registers save/store mechanism during my
> fp calculation.
>
> Anything's wrong or right?
>
It DOES NOT mean that you can execute floating point calculation at
kernel-level.
The problem is that, while context switching, the kernel does not load
the fp registers of the switched-in process until -and if- the
switched-in process requires to do fp math. Instead it sets a bit in a
control register which results to an fp exeption if an fp instruction is
executed. The exception handler restores the fp context of the process.
This means that the fp registers are not saved/restored in each context
switch. If you do fp math in kernel you will either:
1) Mess with the values in the fp registers - if current has used fp
instructions in the current quantum
2) Load fp state and then mess with the values in the fp registers - if
current has not used fp instructions in the current quantum
The problems may -and will- occur in a user-level application having
live values in fp regs. Maybe there was not such an application running
when you executed your experiment...
You certainly could save/restore the registers before/after doing your
math, but it is complicated (you should check if current has already
used math, take care not to cause an fp exception that will restore the
fp state etc...). It is also quite slow - that is why it is not done
during each context switch.
If the fp math you want to do is not too complicated you could perhaps
convert your problen to an equivalent integer one and use it using
integer arithmetic. At least that is what I did in a similar occasion...
Christos Antonopoulos
------------------------------
From: MJ Dainty <[EMAIL PROTECTED]>
Subject: Resources for writing device drivers
Date: Wed, 19 Jul 2000 17:38:20 GMT
Hi,
For my final year project at Uni, I may need to write a kernel device
driver, pretty much from scratch, and I was wondering if anyone can
direct me towards some helpful information.
My list already includes the kernel source tree :) but I was wondering
if there were any good books. I saw the O'Reilly "Linux Device Drivers"
book, and given their reputation, I'm tempted. However the book was
published 1997/98, and I'm concerned that the book may be out of date
given the constantly advancing state of the kernel, so something more
up-to-date would be nice.
Any ideas?
Matt
------------------------------
** 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
******************************
