Linux-Development-Sys Digest #823, Volume #7 Thu, 4 May 00 17:13:15 EDT
Contents:
Re: device driver writing (Rick Ellis)
Re: Device driver trouble (Development System Linux OS)
Re: Device driver trouble (Lew Pitcher)
HELP PLEASSSSSSSSSSSSSSEEEE! (agarwe)
Need help on a Code Launcher project (Eric Taylor)
Re: get_user and bottom half help (Eric Taylor)
Re: Device driver trouble (Development System Linux OS)
Re: gdb on /proc/kcore help? (Eric Taylor)
Re: Device driver trouble (niels)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: device driver writing
Date: 4 May 2000 17:21:18 GMT
In article <8e5k88$l88$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Is this the right list to discuss how to write device driver of linux ?
The best way to start is by reading Linux Device Drivers by Alessandro
Rubini:
http://www.amazon.com/exec/obidos/ASIN/1565922921/ricksphotograpag/
Then come back and ask questions.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: Development System Linux OS <[EMAIL PROTECTED]>
Subject: Re: Device driver trouble
Date: Thu, 04 May 2000 10:39:19 -0700
I am testing the same module from A.RUBINI book:
/* hello.c */
#define MODULE
#include </linux/module.h>
int init_module(void) {printk("<1>Hello World\n"); return 0;}
void cleanup_module(void) {printk("<1>Goodbye World\n");}
% gcc -o hello.o hello.c
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'
/tmp/ccij2Fle.o: In function `init_module':
/tmp/ccij2Fle.o(.text+0x9): undefined reference to `printk'
/tmp/ccij2Fle.o: In function `cleanup_module':
/tmp/ccij2Fle.o(.text+0x21): undefined reference to `printk'
collect2: ld returned 1 exit status
Can you help me to get around with this problem, thanks
Wade
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Lew Pitcher)
Subject: Re: Device driver trouble
Reply-To: [EMAIL PROTECTED]
Date: Thu, 04 May 2000 18:30:08 GMT
On Thu, 04 May 2000 10:39:19 -0700, Development System Linux OS
<[EMAIL PROTECTED]> wrote:
>I am testing the same module from A.RUBINI book:
>/* hello.c */
>#define MODULE
>#include </linux/module.h>
Typo. This should be
#include <linux/module.h>
>int init_module(void) {printk("<1>Hello World\n"); return 0;}
>void cleanup_module(void) {printk("<1>Goodbye World\n");}
>
>% gcc -o hello.o hello.c
>/usr/lib/crt1.o(.text+0x18): undefined reference to `main'
>/tmp/ccij2Fle.o: In function `init_module':
>/tmp/ccij2Fle.o(.text+0x9): undefined reference to `printk'
>/tmp/ccij2Fle.o: In function `cleanup_module':
>/tmp/ccij2Fle.o(.text+0x21): undefined reference to `printk'
>collect2: ld returned 1 exit status
>
>Can you help me to get around with this problem, thanks
>
>Wade
>
>
>
>* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
>The fastest and easiest way to search and participate in Usenet - Free!
>
Lew Pitcher
System Consultant
Toronto Dominion Bank Financial Group
(Opinions expressed are my own, not my employers')
------------------------------
From: agarwe <[EMAIL PROTECTED]>
Subject: HELP PLEASSSSSSSSSSSSSSEEEE!
Date: Thu, 04 May 2000 14:01:24 -0400
==============308E1FAB8C449BA8B8EE0288
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Guys ,
this is a simple question but I need the answer bad...
When I fork , I know that I am starting a new process. When I spwan a
thread, leaving the fact that it has the concept of shared variables, is
that the same as starting a
new process. I read in a book that both fork and spwaning use the same
function clone(). my question then is , is the maximum no of thread s
you can have in a system,
the same as the
no of processes you can have ?
Really need this answer !!
Ekta..([EMAIL PROTECTED])
--
**************************************************************************
Work like you dont need money, * *
Love like you've never been hurt * People Never Fail...They Just*
* Give UP! *
& * *
Dance like no one's watching ......... * *
**************************************************************************
==============308E1FAB8C449BA8B8EE0288
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<br>Guys ,
<br> this is a simple question but I need the answer bad...
<p>When I fork , I know that I am starting a new process. When I
spwan a thread, leaving the fact that it has the concept of shared variables,
is that the same as starting a
<br>new process. I read in a book that both fork and spwaning use the same
function clone(). my question then is , is the maximum no of thread s you
can have in a system,
<br>the same as the
<br>no of processes you can have ?
<p>Really need this answer !!
<p>Ekta..([EMAIL PROTECTED])
<pre>--
**************************************************************************
Work like you dont need
money,
*
*
Love like you've never been hurt
* People Never Fail...They Just*
* Give
UP!
*
&
*
*
Dance like no one's watching .........
*
*
**************************************************************************</pre>
</html>
==============308E1FAB8C449BA8B8EE0288==
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Need help on a Code Launcher project
Date: Thu, 04 May 2000 12:39:46 -0700
Greetings Kernel Hackers:
I need a capability I had on the VMS system
which we called a "CODE LAUNCHER". I think
such a concept is do-able on Linux, but I haven't (yet) the
expertise to do (all of) it.
The launcher became extremely useful and let us do
some very strange (and cool) things.
For example, I could inject periodic sleep calls
into another users program when that user would
monopolize the system by raising his priority above others.
By also re-adjusting some CPU time counters, the
inconsiderate jerk never knew what was up.
This was during the era of timesharing in the 80's - before PC's
when we would have so called "priority wars".
A more legit use of that feature was to simulate a heavy
workload. We could "turn a dial" and change the amount
of work one or several processes could perform. We could do this to
programs we did not even have source to.
=============================================================
Does this sound like a fun project for Linux? If so, read on�
=============================================================
Other uses were to open and close i/o channels to redirect
pipe like devices, flush virtual memory to page files,
flush files to disk on hung processes
and all kinds of interesting hacks:
Such as the one I want to build for Linux:
crawl into another process and record it's
stack frames so that I can dynamically determine what is going
on inside that other process and w/o any prior preparation
or disturbance (that the process notices).
On VMS, this profiler idea eventually became a product which sold
for a few grand a pop! But this is Linux, and I would like to see
it available to all at no cost! But I can't do this myself.
Let me "briefly" describe the code launcher.
================
On the VMS system, there was a way to queue code that would run in
kernel mode but in process context of an arbitrary process. The system
used
this at the end of async I/O and similar events to return status
information to
a process that was not the current process.
But this required that the queued code reside in kernel space.
(the system mode was 1/2 user space, 1/2 kernel space - all
processes shared kernel space - I believe that is the Linux
model now except its 3/4 user and 1/4 kernel).
We couldn't easily use that trick, since that system was not open
source.
Because of that, we were forbidden to modify the operating system.
But this is Linux, so this is more feasible. Still, if it can be done
w/o
hacking the system, all the better. [But because this is Linux, if we
can
come up with a cool innovation, it would (could) probably become part of
the
standard kernel].
Anyway, some hacker then figured out how to run code that was in it's
user space
inside the context of another process. That was the break-thru trick.
But,
the code was real messy. Another hacker (me) built that tricky code into
a re-usable "code launcher" module so we could quickly write a program
that
could run one of it's functions inside another process. The module also
included the key feature of sending a buffer to and returning one from
the
target process. And the launched code needed only to look like this:
launchee(char *inbuf,char *outbuf,....) {
... running inside his process...
make system calls, look around, etc.
stuff outbuf with interesting data
return;
}
This was done by switching to kernel mode, allocating
a kernel buffer, copying (position independent) code into the buffer,
then
inserting a schedule interrupt (similar to a signal) in the target
process.
Then the launching process would go to sleep waiting on a return
interrupt.
(On Linux, I guess this would be implemented as a device driver
function w/o needing to copy the code, just insmod it)
The target process would wake up when next scheduled, see it had an
interrupt
pending, execute the code there (still in kernel mode) send a signal
back to
the calling process and finally clean itself up by dismissing the
interrupt.
Meanwhile, the kernel buffer could include data gathered by
the launchee and upon signaling the launching process,
that process could retrieve the data, and finally de-allocate the kernel
buffer.
If one had to hand code this every time - forget about it! That's why
it had to be modularized.
(Except for the signaling stuff, this seems pretty straight forward for
Linux).
Well, after spending years thinking up all kinds of uses for this
launcher,
VMS and DEC are dinosaurs and I swore I would not spend years
re-learning
some o. s. kernel only to have that system go under.... I believe Linux
is
here to stay, so I think it is time to build a code launcher for Linux.
Then I could use it to build the dynamic code profiler I want and need
for my Linux projects.
==================================
I think the way it would work would be to have a template module that
can read and write to /proc. On a user write to /proc/name the pid of
the
target process and other launcher specific stuff would be sent
to the module. It would use that to schedule an interrupt (signal) for
the
target process. It would then somehow (I don't know this part) execute
that code in kernel mode (out of the module) when next scheduled, saving
any interesting data it finds. It would need to signal back so the
calling
process would wake up and retrieve the gathered info with a read call.
(BTW, on VMS a user process could NOT block these kernel interrupts - I
don't know about Linux and if there are signals that we could use for
this that cannot be blocked)
Launcher.c:
char data_buffer[];
char procinfilename[] = "name-in"; // module cmd line arg supplies name
char procoutfilename[] = "name-out";
init_module() {
set up everything for /proc
}
user_write_function() { // this is a write from the user point of view
user sends in pid to receive launch
queues the signal to the target with
target routine being the below launched_code
waits until we get a signal back
return to caller who now does a read
}
user_read_function() {
send data buffer back to caller
}
cleanup_module() {
}
signal_back() { // cause launcher to wake
}
launched_code() { // this would change for each different launcher
do whatever in the target process
store data in data buffer
signal_back()
}
I am looking for help on this project. I think this can be done,
possibly needing
some kernel modifications, possibly using the existing signaling
mechanism
but once built, other kernel hackers could use this for some really cool
hacks.
Anyone out there intrigued by the idea????
--eric
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: get_user and bottom half help
Date: Thu, 04 May 2000 13:01:23 -0700
Alan Donovan wrote:
>
> Remember the BH is not in process context,
>
I've now (unhappily) become aware of that.
> Most profilers I've seen you can profile subsets of a program's code, by
> indicating which functions are to be instrumented and at which function
> in the code profiling is to begin (then you explicitly call that
> function when ready). Do prof & gprof not support that? Look at man 3
> profil as well.
Problem is that when you have a long running program, like we have, you
don't know ahead of time what functions to instrument. So, when things
suddenly get wierd, that's when you want to take a look.
Also, most profilers that you build in won't report their results until
the end of the run. In our case, that could be days later.
I'm not saying that existing profilers are not worthwhile, just that
after years of using a dynamic profiler, it's made life a lot easier.
Think of the "top" program having an option that let you pick one of the
processes and would give you an updating screen, say every 10 secs, that
displayed a histogram like this:
============================================================
process hog, sample time 10 secs, interval 20ms state all
function hits percent
main 50 30 xxxxxxxxxxxxxxx
sub1 25 15 xxxxxxxx
sub2 5 3 xx
============================================================
(even better is to be able to zoom in by line number)
you run this and within 10 seconds you begin to get your profile.
When you know what's going on, you stop monitoring.
Also, being able to throw out samples according to process state
(running, waiting, all) can tell you where a program spends
it's time only while computing or only while waiting). All this
can be determined in litteraly seconds.
regards
eric
------------------------------
From: Development System Linux OS <[EMAIL PROTECTED]>
Subject: Re: Device driver trouble
Date: Thu, 04 May 2000 12:49:13 -0700
Let me re-type my questions here again!
I am testing the same module from A. RUBINI book:
/* hello.c */
#define MODULE
#include <linux/module.h>
int init_module(void) {printk("<1>Hello World\n"); return 0;}
void cleanup_module(void) {printk("<1>Goodbye World\n");}
% gcc -o hello.o hello.c --after compile I got the following errors
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'
/tmp/ccij2Fle.o: In function `init_module':
/tmp/ccij2Fle.o(.text+0x9): undefined reference to `printk'
/tmp/ccij2Fle.o: In function `cleanup_module':
/tmp/ccij2Fle.o(.text+0x21): undefined reference to `printk'
collect2: ld returned 1 exit status
Can anyone help me to get around with this problem, thanks
Wade
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: gdb on /proc/kcore help?
Date: Thu, 04 May 2000 13:26:43 -0700
Josef Moellers wrote:
>
> Eric Taylor wrote:
> >
> > hi:
> > I'm reading Rubini' driver book and trying to
> > look at some variables i've added to my kernel.
> >
> > In gdb, the symbol addresses are off from when i check
> > /proc/ksyms. Off about 200 bytes or so. My new globals
> > don't show up in ksyms.
> >
> > Do I need to do anything special after a 'make boot' and
> > copy the /usr/src/linux/arch/i386/boot/zImage file into the
> > /boot directory.
> >
> > Do I need to build a special symbol table? How do i get my
> > syms into ksyms.
>
> Don't you have to call the EXPORT_SYMBOL macro with your variables'
> names?
> E.g. look at the contents of
> /usr/src/linux/arch/i386/kernel/i386_ksyms.c
I looked for this file, it's not there. This is my first
kernel build so I'm probably missing lots.
I looked at EXPORT_SYMBOL and that seems to be for
a module. I'm modifying the kernel itself.
As a test, I added an extern in the scheduler, right
before the variable securelevel. I gave it the value 999
to see if i could find it using gdb. In /proc/ksyms, i can
see securelevel, but not my variable. I don't really know how
/proc/ksyms operates, so i don't know what to modify to get
it show up there.
But what my real problem is, is that gdb doesn't seem to get the
right addresses.
What happens is i can see the name of my new variable using
gdb, but it has somehow got the wrong address. And not only for
my variable, but for all the other kernel variables. By asking
it what it thinks is the address of these variables, i can see
by comparing in /proc/ksyms that it does not agree.
Thanks for the help
eric
------------------------------
Date: Fri, 05 May 2000 00:31:54 +0200
From: niels <[EMAIL PROTECTED]>
Subject: Re: Device driver trouble
Development System Linux OS wrote:
> Let me re-type my questions here again!
> I am testing the same module from A. RUBINI book:
> /* hello.c */
> #define MODULE
> #include <linux/module.h>
> int init_module(void) {printk("<1>Hello World\n"); return 0;}
> void cleanup_module(void) {printk("<1>Goodbye World\n");}
>
> % gcc -o hello.o hello.c --after compile I got the following errors
> /usr/lib/crt1.o(.text+0x18): undefined reference to `main'
> /tmp/ccij2Fle.o: In function `init_module':
> /tmp/ccij2Fle.o(.text+0x9): undefined reference to `printk'
> /tmp/ccij2Fle.o: In function `cleanup_module':
> /tmp/ccij2Fle.o(.text+0x21): undefined reference to `printk'
> collect2: ld returned 1 exit status
>
> Can anyone help me to get around with this problem, thanks
>
> Wade
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!
Hi
You are trying to compile the kernel obejct module as a main program, which
will not work for you.
Try doing something like this instead :
gcc hello.c -O2 -D__KERNEL__ -fomit-frame-pointer -c
Regards
Niels
------------------------------
** 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
******************************
