Linux-Development-Sys Digest #262, Volume #8 Wed, 8 Nov 00 00:13:12 EST
Contents:
Re: Porting driver source from 2.2.14 to 2.2.16 (Ed Hudson)
Re: Is that process a thread? (Alexander Viro)
Problems with syslogd [was System call socketcall - recv() called by Linux
continuously ?!?] (Rui Antunes)
Re: Is that process a thread? (George MacDonald)
cross-compile toolchain g++ (Graduate)
Re: cross-compile toolchain g++ (Graduate)
non-portable port (T)
Re: non-portable port (Alexander Viro)
Mouse trouble ("The Dude")
Re: non-portable port ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Ed Hudson <[EMAIL PROTECTED]>
Subject: Re: Porting driver source from 2.2.14 to 2.2.16
Date: Tue, 07 Nov 2000 16:39:44 -0500
Pete,
Here is about 10% of the output from the compile. This is
driving me nuts. I am wondering if there are some headers out of
order or something like that, but not sure. Hopefully, you or someone
in here can shed a little light on it. I am using the new Mandrake
7.2 (kernel 2.2.17) to do the build. I had a similar experience using
a 2.2.16 version of the kernel that I downloaded from www.kernel.org.
Thanks for your help.
Ed
gcc -Iinc -O1 -g3 -Wall -DMODULE -D__KERNEL__ -DMODVERSIONS -DLINUX
-DEXPORT_SYMTAB -c -o cryptic.o src/cryptic.c
In file included from /usr/include/linux/sched.h:13,
from /usr/include/asm/uaccess.h:8,
from inc/compat2_0.h:27,
from src/cryptic.c:48:
/usr/include/linux/times.h:5: parse error before `clock_t'
/usr/include/linux/times.h:5: warning: no semicolon at end of struct
or union
/usr/include/linux/times.h:6: warning: data definition has no type or
storage
class
/usr/include/linux/times.h:7: parse error before `tms_cutime'
/usr/include/linux/times.h:7: warning: data definition has no type or
storage
class
/usr/include/linux/times.h:8: parse error before `tms_cstime'
/usr/include/linux/times.h:8: warning: data definition has no type or
storage
class
In file included from /usr/include/linux/timex.h:142,
from /usr/include/linux/sched.h:14,
from /usr/include/asm/uaccess.h:8,
from inc/compat2_0.h:27,
from src/cryptic.c:48:
/usr/include/linux/time.h:10: parse error before `time_t'
/usr/include/linux/time.h:10: warning: no semicolon at end of struct
or union
/usr/include/linux/time.h:12: parse error before `}'
/usr/include/linux/time.h: In function `timespec_to_jiffies':
/usr/include/linux/time.h:32: dereferencing pointer to incomplete type
/usr/include/linux/time.h:33: dereferencing pointer to incomplete type
/usr/include/linux/time.h: In function `jiffies_to_timespec':
/usr/include/linux/time.h:45: dereferencing pointer to incomplete type
/usr/include/linux/time.h:46: dereferencing pointer to incomplete type
/usr/include/linux/time.h: At top level:
/usr/include/linux/time.h:51: parameter `a' has incomplete type
/usr/include/linux/time.h:51: parameter `b' has incomplete type
/usr/include/linux/time.h: In function `timespec_before':
/usr/include/linux/time.h:55: warning: control reaches end of non-void
function
/usr/include/linux/time.h: At top level:
/usr/include/linux/time.h:60: parameter `a' has incomplete type
/usr/include/linux/time.h:60: parameter `b' has incomplete type
/usr/include/linux/time.h: In function `timespec_less':
/usr/include/linux/time.h:67: dereferencing pointer to incomplete type
/usr/include/linux/time.h:68: dereferencing pointer to incomplete type
/usr/include/linux/time.h: At top level:
/usr/include/linux/time.h:72: parse error before `time_t'
/usr/include/linux/time.h:72: warning: no semicolon at end of struct
or union
/usr/include/linux/time.h:73: warning: data definition has no type or
storage
class
/usr/include/linux/time.h:79: parameter `a' has incomplete type
/usr/include/linux/time.h:79: parameter `b' has incomplete type
/usr/include/linux/time.h: In function `timeval_less':
/usr/include/linux/time.h:86: dereferencing pointer to incomplete type
/usr/include/linux/time.h:87: dereferencing pointer to incomplete type
/usr/include/linux/time.h: At top level:
/usr/include/linux/time.h:92: parameter `tv' has incomplete type
/usr/include/linux/time.h: In function `timeval_to_timespec':
/usr/include/linux/time.h:93: dereferencing pointer to incomplete type
/usr/include/linux/time.h:94: dereferencing pointer to incomplete type
/usr/include/linux/time.h: At top level:
/usr/include/linux/time.h:126: field `it_interval' has incomplete type
/usr/include/linux/time.h:127: field `it_value' has incomplete type
/usr/include/linux/time.h:131: field `it_interval' has incomplete type
/usr/include/linux/time.h:132: field `it_value' has incomplete type
In file included from /usr/include/linux/sched.h:14,
from /usr/include/asm/uaccess.h:8,
from inc/compat2_0.h:27,
from src/cryptic.c:48:
/usr/include/linux/timex.h:163: field `time' has incomplete type
In file included from /usr/include/linux/fs.h:275,
from /usr/include/linux/tty.h:20,
from /usr/include/linux/sched.h:21,
from /usr/include/asm/uaccess.h:8,
from inc/compat2_0.h:27,
from src/cryptic.c:48:
/usr/include/linux/hpfs_fs_i.h:5: parse error before `ino_t'
/usr/include/linux/hpfs_fs_i.h:5: warning: no semicolon at end of
struct or
union
/usr/include/linux/hpfs_fs_i.h:12: parse error before `:'
In file included from /usr/include/linux/fs.h:277,
from /usr/include/linux/tty.h:20,
from /usr/include/linux/sched.h:21,
from /usr/include/asm/uaccess.h:8,
from inc/compat2_0.h:27,
from src/cryptic.c:48:
/usr/include/linux/msdos_fs_i.h:36: parse error before `off_t'
/usr/include/linux/msdos_fs_i.h:36: warning: no semicolon at end of
struct or
union
In file included from /usr/include/linux/fs.h:278,
from /usr/include/linux/tty.h:20,
from /usr/include/linux/sched.h:21,
from /usr/include/asm/uaccess.h:8,
from inc/compat2_0.h:27,
from src/cryptic.c:48:
/usr/include/linux/umsdos_fs_i.h:62: field `msdos_info' has incomplete
type
/usr/include/linux/umsdos_fs_i.h:69: parse error before `off_t'
/usr/include/linux/umsdos_fs_i.h:69: warning: no semicolon at end of
struct
or union
/usr/include/linux/umsdos_fs_i.h:73: parse error before `}'
In file included from /usr/include/linux/fs.h:279,
from /usr/include/linux/tty.h:20,
from /usr/include/linux/sched.h:21,
from /usr/include/asm/uaccess.h:8,
from inc/compat2_0.h:27,
from src/cryptic.c:48:
On Mon, 06 Nov 2000 22:54:56 GMT, [EMAIL PROTECTED] (Pete Zaitcev)
wrote:
>Very mysterious report. Many of my drivers use <asm/uaccess.h>
>with no problems. I think that you would do right to post
>several starting lines from the endless stream of errors that you get.
>But for heaven's sake don't post the whole thing :)
>
>--Pete
>
>On Mon, 06 Nov 2000 14:09:28 -0500, Ed Hudson <[EMAIL PROTECTED]> wrote:
>> I have written a kernel module that builds and runs fine under kernel
>> 2.2.14 and also was tested on 2.0.33. I have found that when I try to
>> build it under 2.2.16 and 2.2.17 I get a nearly endless stream of
>> errors. One that seems to appear quite frequently is in time.h... a
>> parse error before time_t in line 10. Many of the same types of
>> errors occur in xxx_fs.h where every filesystem under the sun is
>> represented by the 'xxx'. The common thread to this problem seems to
>> be the inclusion of <asm/uaccess.h>. Has something changed in this
>> file? If so, any ideas how I can work around this?
>>
>> Thanks,
>> Ed
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: Is that process a thread?
Date: 7 Nov 2000 17:38:20 -0500
In article <[EMAIL PROTECTED]>,
George MacDonald <[EMAIL PROTECTED]> wrote:
>Alexander Viro wrote:
>> The last part is simply wrong - if child, parent and grandparent share VM
>> and parent does exec() we get child and grandparent sharing VM and parent
>> having a separate one. So non-interrupted hierarchy is not promised.
>>
>
>Depends on what's exec'ed, but I see your point. As long as there is shared
>VM the process can be corrupted...
Nope. exec() doesn't modify VM - it creates new one and switches the current
process to that new VM. If there were other users of old VM they keep what
they had. VM is destoryed only when it becomes completely orphaned.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Rui Antunes)
Crossposted-To: comp.os.linux.help,alt.os.linux
Subject: Problems with syslogd [was System call socketcall - recv() called by Linux
continuously ?!?]
Date: Tue, 07 Nov 2000 21:36:24 GMT
I'm developping a module that catches the socket API calls and
(for now) prints some messages on the console and calls the original
socket call.
I'm having some problems: the syslogd (System Logger Daemon) seems
to be calling the recv() function (one of the socket API functions)
all the time.
First, as soon as I inserted the module (using insmod), it started
immediately to detect that syslogd was calling recv() with a socket
file descriptor of 0! - since I print a message to the console every
time that function is called, I get a flooded terminal. However, the
recv() call always returned 0 (no bytes received)...
Now it's behaviour changed (why? - I just don't know...) - I
insert the module and everything stays calm... until I run an
application that calls some of the socket API functions - from there
on, it just keeps detecting that syslogd() keeps on trying to receive
on a socket (sockfd=0) and, this time it's really receiving something:
the string "<4>Nov 6 10:12:11 kernel: RECV DETECTED" (that is, the
priority of printk -<4>- and the string that I'm printing each time a
recv() is detected -RECV DETECTED-, and the month, day and hour...)
Is this normal? What is the syslogd for? (running the man-page for
syslogd I found out that I can turn off syslogd - using: syslogd
-interval 0)
Thanks in advance,
Rui Antunes
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Is that process a thread?
Date: Wed, 08 Nov 2000 01:29:48 GMT
Alexander Viro wrote:
>
> In article <[EMAIL PROTECTED]>,
> George MacDonald <[EMAIL PROTECTED]> wrote:
> >Alexander Viro wrote:
> >> The last part is simply wrong - if child, parent and grandparent share VM
> >> and parent does exec() we get child and grandparent sharing VM and parent
> >> having a separate one. So non-interrupted hierarchy is not promised.
> >>
> >
> >Depends on what's exec'ed, but I see your point. As long as there is shared
> >VM the process can be corrupted...
>
> Nope. exec() doesn't modify VM - it creates new one and switches the current
> process to that new VM.
What if the exec is on the same executable image, does it reuse the existing
virtual memory(text/data but not stack)? Can the new exec then create a new
thread "tree"? Can it create a thread on the old controlling thread?
> If there were other users of old VM they keep what
> they had. VM is destoryed only when it becomes completely orphaned.
Can one lock pages in memory so they stay there even when all processes
die. Let's say I want to keep a shared lib in memory cause I know it's
going to be used again.
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: Graduate <[EMAIL PROTECTED]>
Subject: cross-compile toolchain g++
Date: Tue, 7 Nov 2000 06:48:40 +0000 (UTC)
Hi all,
I don't know whether this is the right newsgroup to post but,
anyway...
I have built a cross-compile toolchain from i686-linux to arm-linux
including binutils 2.10, gcc-core 2.95.2, glibc 2.1.3.
Now, I want to build gnu g++(also cross-compile), I got some error
messages.
I untar gcc-core- and gcc-g++- files and my coufigure command is
configure --prefix=/usr/local/arm --target=arm-linux --host=i686-linux
--with-cpu=strongarm110
Config seems ok...
then make LANGUAGES="g++", some time later, error occurs.
make[2]: Entering directory
/root/package/gcc/gcc-2.95.2/build/arm-linux/libiberty'
make[2]: *** No targets specified and no makefile found. Stop.
make[2]: Leaving directory
/root/package/gcc/gcc-2.95.2/build/arm-linux/libiberty'
make[1]: *** [../libiberty/libiberty.a] Error 2
make[1]: Leaving directory
/root/package/gcc/gcc-2.95.2/build/arm-linux/libstdc++'
make: *** [all-target-libstdc++] Error 2
I checked the config.out files in arm-linux/libiberty. It seems the
following message is the key one.
/usr/local/arm/arm-linux/bin/ld: unrecognised emulation mode: elf32arm
Supported emulations: armelf_linux armelf_linux26 armelf
collect2: ld returned 1 exit status
configure: failed program was:
#line 1760 "configure"
#include "confdefs.h"
main(){return(0);}
I have modified the specs files in /usr/local/arm/lib/gcc-lib/arm-linux/2.96.2
to be something like armelf_linux26, armelf_linux and -p option to build
glibc. Now, should I change it back to elf32arm? I tried to change it but
still the same error messages.
What should I do?
------------------------------
From: Graduate <[EMAIL PROTECTED]>
Subject: Re: cross-compile toolchain g++
Date: Tue, 7 Nov 2000 09:11:30 +0000 (UTC)
: /usr/local/arm/arm-linux/bin/ld: unrecognised emulation mode: elf32arm
: Supported emulations: armelf_linux armelf_linux26 armelf
: collect2: ld returned 1 exit status
: configure: failed program was:
I used "arm-linux-ld -V" and found my linker supports following
emulations, armelf_linux, armelf_linux26, armelf, but no "elf32arm"
supports. My binutils is version 2.10, how can I got the elf32arm
emulation?
Is this some skind of inconsistency between old and new version
of binutils? Do I have some tricks to bypass the config?
: #line 1760 "configure"
: #include "confdefs.h"
: main(){return(0);}
: I have modified the specs files in /usr/local/arm/lib/gcc-lib/arm-linux/2.96.2
: to be something like armelf_linux26, armelf_linux and -p option to build
: glibc. Now, should I change it back to elf32arm? I tried to change it but
: still the same error messages.
: What should I do?
--
~~ 喂-- 喂-- 我是二之宮亞美，聽到我的聲音了嗎？ 現在是8月25日下午9點25分
31秒、32秒••• 氣溫28度夜空晴朗星光閃爍••• 你聽到了嗎？ 我喜歡你。
我是二之宮亞美！ 這是我的回答！
Excerpt from ROUGH by Mitsuru Adachi...
------------------------------
From: T <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: non-portable port
Date: Tue, 07 Nov 2000 19:18:54 -0800
I'd like to revive an old dos project that used inline assembly calls
to BIOS and direct screen writes. Trying to get up to speed with Linux
programming, I've been looking at some sources and reading what I can
find. It looks like both (BIOS calls and direct screen writes) are
verboten and in the domain of the Linux kernel. Learning about modules
and kernel will take too long although I plan to keep at it. I looked
at SVGALib, but my app doesn't need graphics-- it writes to text
screen. Are there any viable approaches (other than give it up:~) and
stuff like curses?
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: 7 Nov 2000 22:58:14 -0500
In article <[EMAIL PROTECTED]>,
T <[EMAIL PROTECTED]> wrote:
>I'd like to revive an old dos project that used inline assembly calls
>to BIOS and direct screen writes. Trying to get up to speed with Linux
>programming, I've been looking at some sources and reading what I can
>find. It looks like both (BIOS calls and direct screen writes) are
>verboten and in the domain of the Linux kernel. Learning about modules
>and kernel will take too long although I plan to keep at it. I looked
>at SVGALib, but my app doesn't need graphics-- it writes to text
>screen. Are there any viable approaches (other than give it up:~) and
>stuff like curses?
<shrug> ncurses, indeed. The only real reasons why DOS stuff needed direct
access to video memory were
* very inefficient implementation of the terminal driver
* general laziness stopping folks from implementing intelligent
redraw algorithms.
The former is not an issue (combination of BIOS and ANSI.SYS was remarkably
slow for no good reason; tty is faster than that). The latter is done in
ncurses. Besides, you don't get to pay for the direct access - stuff works
over telnet, in xterm, etc.
For really intensive use of graphics direct access to hardware may be
needed, but for text... not really.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Reply-To: "The Dude" <[EMAIL PROTECTED]>
From: "The Dude" <[EMAIL PROTECTED]>
Subject: Mouse trouble
Date: Tue, 7 Nov 2000 22:30:39 -0800
I have a mini dinn mouse and keyboard and Linux detected my keyboard but not
my mouse. The mouse works on win98 but not on Linux. Does anyone know what
is wrong or can anyone help out?
send mail to [EMAIL PROTECTED] if you know anything.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: Wed, 08 Nov 2000 04:36:56 GMT
[EMAIL PROTECTED] (Alexander Viro) writes:
> In article <[EMAIL PROTECTED]>,
> T <[EMAIL PROTECTED]> wrote:
> >I'd like to revive an old dos project that used inline assembly calls
> >to BIOS and direct screen writes. Trying to get up to speed with Linux
> >programming, I've been looking at some sources and reading what I can
> >find. It looks like both (BIOS calls and direct screen writes) are
> >verboten and in the domain of the Linux kernel. Learning about modules
> >and kernel will take too long although I plan to keep at it. I looked
> >at SVGALib, but my app doesn't need graphics-- it writes to text
> >screen. Are there any viable approaches (other than give it up:~) and
> >stuff like curses?
>
> <shrug> ncurses, indeed. The only real reasons why DOS stuff needed direct
> access to video memory were
> * very inefficient implementation of the terminal driver
> * general laziness stopping folks from implementing intelligent
> redraw algorithms.
I thought the _real_ big deal was the fact that BIOS didn't offer a
"string" function; in order to output 60 characters, you had to bounce
60 interrupts at the system. None too efficient...
> The former is not an issue (combination of BIOS and ANSI.SYS was
> remarkably slow for no good reason; tty is faster than that). The
> latter is done in ncurses. Besides, you don't get to pay for the
> direct access - stuff works over telnet, in xterm, etc.
>
> For really intensive use of graphics direct access to hardware may be
> needed, but for text... not really.
I do remember there being some _appallingly_ slow rendering of text on
Sun 2's when running in console mode; that was, of course, when Sun
2's were considered reasonably powerful :-).
--
(concatenate 'string "cbbrowne" "@hex.net") <http://www.ntlug.org/~cbbrowne/>
"If women don't find you handsome, they should at least find you
handy..." -- The Red Green Show
------------------------------
** 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
******************************
