Linux-Development-Sys Digest #725, Volume #7 Sun, 2 Apr 00 04:13:09 EDT
Contents:
How can I redirect Messages. (Myint)
Re: How can I redirect Messages. (Kaz Kylheku)
Re: How can I redirect Messages. ("D. Stimits")
Re: System.map location (Jerry Peters)
Where's the dang source? ([EMAIL PROTECTED])
Re: Free BSD (Arun Sharma)
Re: Where's the dang source? ("Peter T. Breuer")
Re: interruptible_sleep_on() problem... ("Norm Dresner")
Re: How do I make shared libraries? (Allin Cottrell)
Re: New Linking errors in RH6.1 ("Daniel Beer")
Re: System.map location ("D. Stimits")
----------------------------------------------------------------------------
From: Myint <[EMAIL PROTECTED]>
Subject: How can I redirect Messages.
Date: Sat, 01 Apr 2000 20:30:11 GMT
During bootup lost of messages go out of the screen. I like to read it.
How can I redirect to a file or any where I can openfile and look at it.
Thanks,
Myint
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: How can I redirect Messages.
Reply-To: [EMAIL PROTECTED]
Date: Sat, 01 Apr 2000 20:44:23 GMT
On Sat, 01 Apr 2000 20:30:11 GMT, Myint <[EMAIL PROTECTED]> wrote:
>During bootup lost of messages go out of the screen. I like to read it.
>How can I redirect to a file or any where I can openfile and look at it.
man dmesg
--
#exclude <windows.h>
------------------------------
Date: Sat, 01 Apr 2000 13:55:31 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How can I redirect Messages.
Myint wrote:
>
> During bootup lost of messages go out of the screen. I like to read it.
> How can I redirect to a file or any where I can openfile and look at it.
>
> Thanks,
> Myint
>
> --
> Posted via CNET Help.com
> http://www.help.com/
You might want to just use "dmesg". Or, depending on distributions,
the various log files in /var/log/. Additionally, logging of bootup
messages can usually be altered with files in /etc/ (see klogd and
syslogd man pages).
------------------------------
From: Jerry Peters <[EMAIL PROTECTED]>
Subject: Re: System.map location
Date: Sat, 01 Apr 2000 21:53:51 GMT
D. Stimits <[EMAIL PROTECTED]> wrote:
> Moritz Franosch wrote:
>>
>> "D. Stimits" <[EMAIL PROTECTED]> writes:
>>
>> > I'm trying to find out where in the kernel it decides that it must
>> > read /boot/System.map, so I can create alternate locations and names.
>> > I'd like to boot multiple kernels without having to repoint sym links
>> > first.
>>
>> You can call the file System.map-`uname -r` (e.g. System.map-2.2.14).
>>
>> Moritz
> So far this seems to work best. It simply requires compiling the
> EXTRAVERSION info into each kernel. My only problem with this is that
> all kernels must have different minor versioning added to them. If
> System.map could be explicitly stated at one location (each
> application using System.map has its own search hierarchy *compiled*
> in, rather than using a query from the kernel or a config file),
> kernels and System.map files could be stored as pairs, in a more
> organized sub directory structure, like /boot/2.2.14/smp/,
> /boot/2.2.14/uni/, so on.
So, have one of your startup scripts symlink from /boot/whatever/somemore/
System.map to /boot/System.map or wherever else you need it.
Jerry
> Admittedly though, this is a bit of nitpicking. I wouldn't have even
> noticed it if not for the number of testing configurations I've gone
> through lately. Modules that are not part of the kernel require
> recompiling for every minor version number, even if the rest of the
> changes in the kernel are irrelevant to the module.
------------------------------
From: [EMAIL PROTECTED]
Subject: Where's the dang source?
Date: Sat, 01 Apr 2000 21:50:13 GMT
For an open source project, the linux source code is surprisingly hard
to find. I've been looking at various linux sites for the source code of
the OS for over an hour and have gotten no closer than some tantalizing
references to the CVS being used. Can someone please drop me an email
with the address? Thanks
-Carl
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Arun Sharma)
Subject: Re: Free BSD
Reply-To: [EMAIL PROTECTED]
Date: Sat, 01 Apr 2000 22:10:07 GMT
On Sat, 01 Apr 2000 07:45:30 -0600, Robert Redelmeier <[EMAIL PROTECTED]> wrote:
> `gcc`. I have conflicting reports on whether BSD has it's
> own libs. FreeBSD uses glibc for Linux compatibility (when
> intalled).
FreeBSD has its own C library. Look in /usr/src/lib/libc on a FreeBSD box
with sources.
-Arun
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Where's the dang source?
Date: 1 Apr 2000 22:07:13 GMT
[EMAIL PROTECTED] wrote:
: For an open source project, the linux source code is surprisingly hard
: to find. I've been looking at various linux sites for the source code of
How can you not see it? It's on every archive site in the universe.
And on every distro. Is it possible that you are not recognizing it
when you are seeing it?
Go to www.kernel.org for starters.
: the OS for over an hour and have gotten no closer than some tantalizing
: references to the CVS being used. Can someone please drop me an email
: with the address? Thanks
Peter
------------------------------
Reply-To: "Norm Dresner" <[EMAIL PROTECTED]>
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Re: interruptible_sleep_on() problem...
Date: Sun, 02 Apr 2000 00:36:36 GMT
I have successfully used interruptible_sleep_on to queue multiple requests
to a kernel module from user-space. It's very hard to figure out what's
wrong with your sketchy description, but the first thing I would suggest is
to simplify as much as possible, perhaps having only one process waiting at
a time. That way you should get (at most) only a few error messages. Also
some code snippets would be useful.
Norm
Badrinath Venkatachari <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
> I am trying to capture all read requests in the kernel, queue them up
> and process them every some seconds out of sync with the requesting
> process's context...for this my code is :
>
> The processing of Qing requests is started when an LKM is a loaded.
> This LKM sets a flag and starts a timer for a function to deQ requests
> periodically. Since a requests are handled out of the context of the
> process requesting the data blocks, I have the process sleeping on
> wait_queue till the buffer_head has been serviced by the timer driven
> function. this wait_queue is a part of the node (struct req) that gets
> Qued since I need to know which process to wakeup....I am trying to
> maintain a 1-1 correspondence between struct req and the process for
> which it is created...so that wake_up would do so the only process that
> should be woken up.
>
> But there is something wrong in my assumptions and code that make the
> system just report all sorts of errors....just too many to capture and
> put here...but the bottomline being that is this mechanism does not
> work....I am inclined to believe that there is may be something else
> that I have to do apart from interruptible_sleep_on ??? I have pasted
> the necessary code....
>
> Please help....any ideas or pointers would be greatly appreciated....
>
> thanks a lot in advance
>
> regards
> badri
>
> ---- Code ----
>
> struct semaphore semQ = MUTEX;
> struct req /* this is the node added to the Q to hold information about
> a read
> request */
> {
> int major, rw;
> struct buffer_head *bh;
> struct wait_queue *wq; /* the requesting process's context is stored
> here and used later by the timer function to wake_up the appropriate
> process after issuing make_request and getting the buffer_head filled*/
> struct req *next;
> };
>
> /* this function replaces make_request() in ll_rw_block() for only read
> operations*/
> Q_request(int major, int rw, struct buffer_head *bh)
> {
> if (! flag)
> make_request(major, rw, bh);
> else
> {
> struct req *rq;
> rq = (struct req*) kmalloc(sizeof(struct req), GFP_ATOMIC);
> rq->major = major; rq->rw = rw; rq->bh = bh;
> rq->wq= NULL; rq->next = NULL;
> /* Q the request */
> down(&semQ);
> addRequestToQ(rq); /* adds this request to a Q by encapsulating it
> in another
> struct req*/
> up(&semQ);
> interruptible_sleep_on(&rq->wq);
> }
> }
>
>
> /* a timer driven function to deQ requests and process them */
> void serviceRequests()
> {
> struct req *rq;
> /* code for creating a timer to call itself once again after
> sometime*/
>
> /* service requests out of the requesting processes context */
> for (i = 0; i < 5; i ++)
> {
> down(&semQ);
> deQrequest(rq);
> up(&semQ);
> make_request(rq->major, rq->rw, rq->bh);
> wake_up_interruptible(&rq->wq); /* I am hoping the rq->wq will
> still have the context of the process that created this rq in the first
> place
> }
> }
>
>
------------------------------
From: Allin Cottrell <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: How do I make shared libraries?
Date: Sat, 01 Apr 2000 20:27:42 -0500
"Marc E. Christensen" wrote:
> What is nessasery to make a '.so' instead of a
> '.a' on Linux with egcs-2.91.66?
Why is anyone still using egcs? The egcs developments were merged
back into gcc (2.95.N) a long time since.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
------------------------------
Crossposted-To:
comp.os.linux.development.apps,linux.dev.c-programming,linux.redhat.devel
Subject: Re: New Linking errors in RH6.1
From: "Daniel Beer" <[EMAIL PROTECTED]>
Reply-To: "Daniel Beer" <[EMAIL PROTECTED]>
Date: Sun, 2 Apr 2000 16:48:26 +1300
On Thu, 30 Mar 2000 09:38:24 -0600, "Timothy Burgener"
<[EMAIL PROTECTED]> wrote:
>We've been building under RH5.0 to 5.2 without any problems with some of our
>source files. However, now that we've upgraded to 6.1, we are getting weird
>link errors everytime. The errors are only with base class references
>(which an instance is never made of). However, we have 100's of other base
>classes used in a variety of ways that do not generate errors, and they are
>never declared as specific objects either. We are using the exact same
>source/header/make files for building under 6.x that work fine under 5.x.
>
>The specific error is one we've never seen before. It has the form:
>sourcefile.cpp:999[last line # of file]: undefined reference to `[Base
>class name] type_info function`
>sourcefile.cpp:999[last line # of file]: undefined reference to `[Base
>class name] type_info node`
>
>What the heck is type_info function??? Is this name mangling? gcc? RH6.1?
>kernel 2.2.x?
>
>As you can see, I am at a loss. Below is an excerpt of actual error
>listing:
>==========
>.../output/pltlinux.o: In function `cPlatformLinux type_info function':
>/home/jbmgatew/gtwy1000/output/../source/pltlinux.cpp:182: undefined
>reference t
>o `cPlatformInterface type_info function'
>/home/jbmgatew/gtwy1000/output/../source/pltlinux.cpp:182: undefined
>reference t
>o `cPlatformInterface type_info node'
>.../output/tnhdpar.o: In function `cTn3270MsgParser type_info function':
>/home/jbmgatew/gtwy1000/output/../source/tnhdpar.cpp:442: undefined
>reference to
> `cMsgHeaderParser type_info function'
>/home/jbmgatew/gtwy1000/output/../source/tnhdpar.cpp:442: undefined
>reference to
> `cMsgHeaderParser type_info node'
>collect2: ld returned 1 exit status
>make: *** [gwlnx] Error 1
>
>
>
Have you tried doing a full compile? Start with "make clean". It may
be that the version of gcc that comes with Redhat 6.1 has a different
way of creating/recognising object code.
--
_ _
o' \,=./ `o Daniel Beer <[EMAIL PROTECTED]>
(o o) dlbeer.freeshell.org
ooO--(_)--Ooo-
------------------------------
Date: Sat, 01 Apr 2000 22:00:20 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: System.map location
Jerry Peters wrote:
>
> D. Stimits <[EMAIL PROTECTED]> wrote:
> > Moritz Franosch wrote:
> >>
> >> "D. Stimits" <[EMAIL PROTECTED]> writes:
> >>
> >> > I'm trying to find out where in the kernel it decides that it must
> >> > read /boot/System.map, so I can create alternate locations and names.
> >> > I'd like to boot multiple kernels without having to repoint sym links
> >> > first.
> >>
> >> You can call the file System.map-`uname -r` (e.g. System.map-2.2.14).
> >>
> >> Moritz
>
> > So far this seems to work best. It simply requires compiling the
> > EXTRAVERSION info into each kernel. My only problem with this is that
> > all kernels must have different minor versioning added to them. If
> > System.map could be explicitly stated at one location (each
> > application using System.map has its own search hierarchy *compiled*
> > in, rather than using a query from the kernel or a config file),
> > kernels and System.map files could be stored as pairs, in a more
> > organized sub directory structure, like /boot/2.2.14/smp/,
> > /boot/2.2.14/uni/, so on.
>
> So, have one of your startup scripts symlink from /boot/whatever/somemore/
> System.map to /boot/System.map or wherever else you need it.
>
> Jerry
If I use the same kernel name but simply point at different
subdirectories, how will the script know which kernel was actually
booted, in order to do the right sym link? I'd be back to creating
EXTRAVERSION changes for every kernel and thus for every module that
isn't part of the kernel compile.
It isn't a particularly important problem, and most people will never
need to worry about a dozen kernels, but it is annoying at times when
needed. I wish there was a *simple* way to specify which System.map to
use, but it really is more of an issue of the various applications
that use it, rather than the kernel. On the other hand, it would be
nice if the kernel had a query_system_map_path() function to return a
path that could be compiled in to the kernel, directly; unfortunately,
all the apps would also have to be rewritten to use this.
Since there is exactly one System.map per kernel, paired to match the
one kernel, it would make sense for the kernel to have that
information embedded in it, and for applications to ask the kernel
which map to use. An entire set of paths could even be used, such as
"/System.map:/boot/System.map:/usr/src/linux/System.map" being the
default if there was no manual override.
>
> > Admittedly though, this is a bit of nitpicking. I wouldn't have even
> > noticed it if not for the number of testing configurations I've gone
> > through lately. Modules that are not part of the kernel require
> > recompiling for every minor version number, even if the rest of the
> > changes in the kernel are irrelevant to the module.
------------------------------
** 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
******************************
