Linux-Development-Sys Digest #699, Volume #8 Mon, 7 May 01 18:13:11 EDT
Contents:
Re: Is linux kernel preemptive?? (Neal Tucker)
Re: How to get a number of processors (John Beardmore)
lilo version 21.7.5 update (John in SD)
Re: losing bottom halves (Greg Copeland)
bootp server replies being ignored by bootp client ("Jim Fischer")
Driver functions after a Segmentation Error ("Norm Dresner")
Re: losing bottom halves
Re: Driver functions after a Segmentation Error
Re: How to get a number of processors ("Norman Black")
file read problem (yan zhang)
Re: Driver functions after a Segmentation Error ("Norm Dresner")
where do I see dprintk messages ([EMAIL PROTECTED])
Re: Linux, streams and the standard library (John Beardmore)
Re: How to get a number of processors (Stefaan A Eeckels)
Re: How to get a number of processors (Stefaan A Eeckels)
Re: How to get a number of processors (Stefaan A Eeckels)
Re: file read problem (Juergen Heinzl)
Re: Driver functions after a Segmentation Error
Re: where do I see dprintk messages
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Neal Tucker)
Subject: Re: Is linux kernel preemptive??
Date: 7 May 2001 11:29:55 -0700
Greg Copeland <[EMAIL PROTECTED]> wrote:
>
>As for the laymen reference, many people read this group so they
>can learn something. I know I do. Many people may not care
>enough to know every nut and bolt, however, they may want enough
>to answer their basic question.
I'm here to learn something, too. But given that this is a kernel
programming newsgroup, if there's stuff I don't understand, I'd be
way out of line asking the discussors to tone it down for the laymen.
Sure, when I'm talking to my boss, I don't go into every programming
detail, but if he interrupted an engineering meeting and asked us to
quit talking about technical details, we'd start having our meetings
in places he can't find.
-Neal Tucker
------------------------------
From: John Beardmore <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: Mon, 7 May 2001 19:31:44 +0100
In message <[EMAIL PROTECTED]>, Nix
<$}xinix{[email protected]> writes
>On Mon, 7 May 2001, John Beardmore yowled:
>> Guaranteeing resources to processes may be a good tool, but it isn't
>> an alternative to knowing how many threads to create for a big
>> crunching job. For that, you still need to know the number of
>> available processors.
>
><pedant>
>No, you need to know the number of simultaneously executing tasks, which
>is quite a different thing (or it could be, on high-end systems).
Well what you really want to do is match the number of high priority
threads to processors.
>The number of physical lumps of doped silicon inside the machine is an
>irrelevant hardware detail.
Nonsense.
Cheers, J/.
--
John Beardmore
------------------------------
From: John in SD <[EMAIL PROTECTED]>
Subject: lilo version 21.7.5 update
Reply-To: [EMAIL PROTECTED]
Date: Mon, 07 May 2001 18:34:29 GMT
LILO release 21.7.5 is based upon Werner Almesberger's LILO version 21.
Version 21.7.5 is a bugfix release.
Version 21.7 adds support for higher serial line rates.
Version 21.6 is an upgrade for users of the Reiser File System, and adds
new diagnostic capabilities. Internal changes allow booting kernels with
larger real-mode setup codes (2.4.0 and later).
Source code is available for download from:
ftp://brun.dyndns.org/pub/linux/lilo (developer's site)
Or from the main distribution site:
ftp://metalab.unc.edu/pub/Linux/system/boot/lilo (please use)
See the distribution file 'CHANGES' for details of the differences between
21.7.5 and prior releases.
--John Coffman <[EMAIL PROTECTED]>
LILO version 21.7 (24-Feb-2001) source at
http://www.ibiblio.org/pub/Linux/system/boot/lilo
patches to -2 at ftp://brun.dyndns.org/pub/linux/lilo
------------------------------
Subject: Re: losing bottom halves
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 07 May 2001 13:40:41 -0500
I didn't take that mean that it is flawed, but I do believe that it is a
true statement. After all, wasn't that one of the primary reasons for the
split irq handlers that Linux uses? Fast top half called on the IRQ, slower?
bottom half to be called when able.
Sorry if you were being sarcastic and I missed it...
[EMAIL PROTECTED] () writes:
> In article <9d5od2$bqg$[EMAIL PROTECTED]>,
> Barry Smyth <[EMAIL PROTECTED]> wrote:
>
> >I have transfered all my Bottom Half code directly into the isr, since the
> >bottom half cannot be guaranteed to execute before the next interrupt
> >arrives.
>
> You say that as though it were some kind of flaw.
>
> --
> http://www.spinics.net/linux
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: "Jim Fischer" <[EMAIL PROTECTED]>
Subject: bootp server replies being ignored by bootp client
Date: Mon, 7 May 2001 11:44:08 -0700
I've got a Linux client whose 2.4.3 kernel is configured to generate
BOOTP requests to obtain the host machine's IP address at boot-up. The
kernel is indeed sending out BOOTP requests but it's ignoring the
replies from the BOOTP server. Any ideas why this would be happening
???
FWIW, I've sniffed the network with 'ethereal' v0.8.17 during the
BOOTP transactions between the client and server and have confirmed
that: a ) the BOOTP server is responding to the client's BOOTP
requests, and b) the packets are arriving at the ethernet hub that the
BOOTP client is connected to. Furthermore, the responses contain the
correct information -- e.g., the client's IP address, the file name of
the client's kernel (relative to the BOOTP server's file system), the
directory on the BOOTP server that the client should mount via NFS as
its root file system, etc.
FWIW2, I've added the following debug statements to the beginning of
the 'ic_boot_recv()' function in 'linux/net/ipv4/ipconfig.c' (in the
2.4.3 source tree), but the '<--here--> etc.' debug message (see
below) is never printed -- i.e., it seems the 'ic_bootp_recv()'
function is never called, even though the bootp server is sending back
well-formed reply packets.
--- begin patch ---
diff -Nuar /old/linux/net/ipv4/ipconfig.c linux/net/ipv4/ipconfig.c
--- /old/linux/net/ipv4/ipconfig.c Fri Feb 9 11:34:13 2001
+++ linux/net/ipv4/ipconfig.c Mon May 7 00:28:10 2001
@@ -44,7 +44,7 @@
#include <asm/checksum.h>
/* Define this to allow debugging output */
-#undef IPCONFIG_DEBUG
+#define IPCONFIG_DEBUG
#ifdef IPCONFIG_DEBUG
#define DBG(x) printk x
@@ -634,6 +634,9 @@
struct bootp_pkt *b = (struct bootp_pkt *) skb->nh.iph;
struct iphdr *h = &b->iph;
int len;
+#ifdef IPCONFIG_DEBUG
+printk( "<--here--> %s() called...\n" __FUNCTION__ );
+#endif
/* If we already have a reply, just drop the packet */
if (ic_got_reply)
--- end patch ---
Any ideas what's going on here? (BTW, I'm using a 3Com 3c905C NIC and
its driver is compiled into the kernel...)
Jim
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Driver functions after a Segmentation Error
Date: Mon, 07 May 2001 19:33:31 GMT
A driver I was writing failed with a Segmentation Error because of some
stupid things I did. But after that happened, I ran a few programs of mine
to try to isolate the failure. Several were observed to run properly because
I could see the proper signals on a 'scope, but the system log written to
via printk was never updated after that failure (I could tell this because
those same functions are known to write several unique messages to the log.)
Is it somehow normal behavior that a driver can be invoked after a seg-error
but it can't update the system log? I'd really like to get an explanation
for why this happened.
Thanks
Norm
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: losing bottom halves
Date: Mon, 07 May 2001 19:46:24 -0000
In article <[EMAIL PROTECTED]>,
Greg Copeland <[EMAIL PROTECTED]> wrote:
>I didn't take that mean that it is flawed, but I do believe that it is a
>true statement. After all, wasn't that one of the primary reasons for the
>split irq handlers that Linux uses? Fast top half called on the IRQ, slower?
>bottom half to be called when able.
But why should anything prevent an interrupt happening before the bh
is executed? The idea was allow some processing to be done outside of
the interrupt handler. But that doesn't mean it'll happen before anything
else. All that marking the bh to run does is mean it will run sometime
in the future. When your bh runs it should insure that it does all the
work that is ready to be done and not assume that only one interrupt
has happened. If you can't do that, why bother with a bh at all?
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Driver functions after a Segmentation Error
Date: Mon, 07 May 2001 19:49:30 -0000
In article <fMCJ6.8780$[EMAIL PROTECTED]>,
Norm Dresner <[EMAIL PROTECTED]> wrote:
>Is it somehow normal behavior that a driver can be invoked after a seg-error
>but it can't update the system log? I'd really like to get an explanation
>for why this happened.
What did the driver destroy with its wild memory access? It could have
hit something that printk depends on. A seg fault in the kernel isn't
a Good Thing and it is hard to say what you might have touched.
--
http://www.spinics.net/linux
------------------------------
From: "Norman Black" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: Mon, 7 May 2001 13:13:38 -0700
Reply-To: "Norman Black" <[EMAIL PROTECTED]>
I use _SC_NPROCESSORS_ONLN on both Linux and Solaris.
--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom
"Greg Copeland" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Oddly enough, my man page for sysconf doesn't show the
_SC_NPROCESSORS_CONF
> option. Hmm....wonder how long it's been around. Does it exist for
Linux?
>
> Thanks,
> Greg
>
>
> Chris <[EMAIL PROTECTED]> writes:
>
> > Hong Hsu wrote:
> > >
> > > Hi all,
> > >
> > > Here is my quick question. My application needs to know how many
> > > processors running in the host machine, is there API which allows me
to
> > > get a number of processors?
> >
> > sysconf(2); /usr/include/bits/confname.h
> >
> > i.e.
> >
> > printf("%d\n", sysconf(_SC_NPROCESSORS_CONF));
> >
> > --
> > Chris Lightfoot -- chris at ex dash parrot dot com --
www.ex-parrot.com/~chris/
> > Sometimes I lie awake at night and ask ``Why me?'' Then a voice
> > answers ``Nothing personal, your name just happened to come up.''
> > (Charlie Brown, from `Peanuts', Charles Schultz)
>
> --
> Greg Copeland, Principal Consultant
> Copeland Computer Consulting
> --------------------------------------------------
> PGP/GPG Key at http://www.keyserver.net
> DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
> --------------------------------------------------
------------------------------
From: yan zhang <[EMAIL PROTECTED]>
Subject: file read problem
Date: Mon, 07 May 2001 16:37:17 -0500
I have a function called read_file_to_string. In this function, I tried
to use file->f_op->read to read a text file from local directory. I can
open it without problem but when I read it, linux system crashed.
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Re: Driver functions after a Segmentation Error
Date: Mon, 07 May 2001 21:42:03 GMT
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> In article <fMCJ6.8780$[EMAIL PROTECTED]>,
> Norm Dresner <[EMAIL PROTECTED]> wrote:
>
> >Is it somehow normal behavior that a driver can be invoked after a
seg-error
> >but it can't update the system log? I'd really like to get an
explanation
> >for why this happened.
>
> What did the driver destroy with its wild memory access? It could have
> hit something that printk depends on. A seg fault in the kernel isn't
> a Good Thing and it is hard to say what you might have touched.
>
> --
> http://www.spinics.net/linux
There were two errors in the module, the first an attempted read access of
user-space -- copy_from_user() -- and the second a write back to the same
address. Both used the same (erroneous) pointer. I don't see how the
second could have trashed something because if its address was seg-faulting,
the first access would have too.
Norm
------------------------------
From: [EMAIL PROTECTED]
Subject: where do I see dprintk messages
Date: Mon, 07 May 2001 21:45:28 GMT
I am using function calls from mm/memory.c. What do I have to do to see the
dprintk messages. I see my printk messages in /var/log/messages. Is there
special compile time flag I have to use and where should I expect them.
------------------------------
From: John Beardmore <[EMAIL PROTECTED]>
Subject: Re: Linux, streams and the standard library
Date: Mon, 7 May 2001 22:46:43 +0100
In message <[EMAIL PROTECTED]>, David Konerding
<[EMAIL PROTECTED]> writes
>If you want standard C++ with the standard C++ library on Linux, and
>you are using RH 6.2, then download gcc-2.95.3, compile and install it
>according to the instructions, then download STLport-4.0 from
>www.stlport.org, and install it according to its instructions. Compile
>your apps to use the header files from STLport and link against the
>STLport library.
OK, have got 2.95.3 installed as /usr/local/bin etc and the old compiler
still resides in /usr/bin. I assume that's how it should be ?
I've had some success with 2.95.3 and had hoped to avoid installing
STLport, however I've come to grief again and I'm looking at the STLport
instructions. Early in the instructions it says:
2) Make sure the "stlport" directory of this distribution comes before
the
compiler's one in your search path when you compile the project;
How do you configure that ? cpp -v shows me the include paths searched,
but I don't know how to add the stlport directory, and in particular how
to add it at the head rather than the tail of the path list. Am I
missing something obvious ?
Cheers, J/.
--
John Beardmore
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: How to get a number of processors
Crossposted-To: comp.os.linux.development.apps
Date: Mon, 7 May 2001 22:53:25 +0200
In article <[EMAIL PROTECTED]>,
John Beardmore <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]>, Stefaan A Eeckels
> <[EMAIL PROTECTED]> writes
>>In article <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] (Dave Blake) writes:
>>> Eric P. McCoy <[EMAIL PROTECTED]> wrote:
>>>
>>>> This strikes me as a battle of bad ideas: I hate writing a
>>>> text parser to deal with /proc; I don't like using nonstandard
>>>> pieces of code; and no program should ever need to know how
>>>> many processors are in a given box. There are cases where
>>>> you'd want to use one or all of these bad ideas, but I, for
>>>> one, would need a pressing reason.
>>>
>>> Suppose I am writing a data crunching piece of software that
>>> parallelizes easily, and wish to run a thread on each processor.
>>>
>>> I first parse /proc/stat, and then crunch away with a thread
>>> on each CPU.
>>>
>>> For a web searching program, you may wish to know the number of
>>> NICs and CPUs, and take the lower of the two as the number of
>>> threads to run. And so on.
>>
>>In a Unix system, the application should not need to know
>>anything about the hardware details.
>
> <dOGMA aLERT !>
>
> Well then, in that case, why don't YOU start the project to make gcc
> exploit all possible opportunities for parallelism ?
Maybe because I don't have a need for them?
>> The recent obsession
>>with threads violates that basic tenet.
>
> You sound if you find threads morally objectionable as opposed to 'just
> another way to get the job done'.
No. It's a step back from the level of hardware abstraction
that set Unix aside from the OSes of its generation. Worrying
about the differences between hardware is typically something
that needs to be done by the OS; putting it in an application
is bound to yield suboptimal, or even wrong results when the
hardware doesn't match the assumptions made by the application.
And as applications typically outlive hardware by many, many
years (and maintenance programmers couldn't bother less), it's
a bad strategy.
>
>> If one wants to
>>squeeze the last ounce of performance from a box,
>
> But it's not the 'last ounce' ! On some boxes it's most of the ounces !
>
>
>> don't
>>use an OS.
>
> Oh balls.
>
> 'Use an OS and a compiler that knows about parallelism'
Then you will get most of the ounces, but not the last ounce,
agreed.
And I also agree that the OS (and associated tools) should be
capable of using the hardware to a reasonable extend, and do
so in a way that ensures that the application is not burdened
with irrelevant details such as the number of processors, the
size of the memory, or for that matter, the layout of the blocks
on a disk drive.
COBOL has statements that allow some control over the layout
and blocking factor of a file on disk. Leaving it to the OS
wasn't an option, as OS and hardware _needed_ help in putting
the file on disk in a not too inefficient manner. Suggesting
that such should be possible on today's disks would be met with
hoots of derision.
I'm merely suggesting that scheduling threads, worrying about
synchronization, and adapting the behaviour of an application
to the number of processors _should_ be handled by the OS, and
that the Unix approach is exactly to hide details of hardware
from the applications (everything is a file, remember?).
>
> might be a better assertion, but pausing briefly to live in the real
> world, C is not terribly 'parallel aware', and gcc is what most us here
> want to work with.
Correct. And the solution is _not_ to add a syscall to Unix
to get at the number of processors, but to find a way to
avoid having to know how many processors we've got, like we
don't want to know how fast a disk spins to decide how we'll
open a file, or how many dots per inch a printer has before
we generate PostScript.
> I don't see any moral problem with C and Linux supporting threads. Even
> on single CPU machines this can speed up some IO operations with
> simultaneous reads on more than one device for example. I really don't
> see the point in coming over all 'closed minded' about it.
Why do you interpret my remark as "close mindedness"? Maybe
this is an area where Linux can further the state of the art,
and prove that the Unix paradigm can handle multi-processors
and threading in a betterm more portable and more transparent
way than POSIX threads and querying the number of CPUs in a box.
>
> Now if you're going to make the number of threads equal the number of
> processors for some crunching task, WTF is wrong with the OS making that
> info available ?? It's only one integer and nobody's forcing YOU to use
> it if you object on religious grounds.
Because on any multi-tasking box, the presence of persitent
service processes, and other applications, this is an example
in misguided micro-optimization. What you should tell the OS
is that you want to run as many threads as possible. And maybe
you shouldn't have to worry about threads either; indicating
what you want the OS to run simultaneously should suffice.
--
Stefaan
--
How's it supposed to get the respect of management if you've got just
one guy working on the project? It's much more impressive to have a
battery of programmers slaving away. -- Jeffrey Hobbs (comp.lang.tcl)
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: How to get a number of processors
Crossposted-To: comp.os.linux.development.apps
Date: Mon, 7 May 2001 23:25:18 +0200
In article <[EMAIL PROTECTED]>,
Greg Copeland <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Stefaan A Eeckels) writes:
>
>> In article <[EMAIL PROTECTED]>,
>> Greg Copeland <[EMAIL PROTECTED]> writes:
>> >
>> > I strongly disagree with the assertion that no one would ever need to know
>> > how many processors there are in a system. I have worked on some large UNIX
>>
>> Maybe the OS should provide a service to ensure that certain
>> processes get a minimum of CPU time. The approach you describe
>> is a hack, and goes completely against the basic Unix concept
>> of hiding the hardware differences and specifics from the
>> applications.
>
> I *completely* disagree with you. You are unable to get past the simple fact that
> parallel computing has requirements above and beyond simple server programming
> where you are using a pool of processes/threads or even a 1:1 process/thread per
> client. Actually, let's talk about those for a second. If you are no longer
> using a 1:1 model of process/thread per client, then it's safe to assume you've
> come to an scalability impasse where you decided that a pool of resources will
> scale better. Why do you supposed that you hit the wall and was forced to change
> models? In the above cases, you are assuming that you are the only processes with
> significant priority on it, as obviously, a heavily loaded system will, by far,
> not be servicing clients and other applications fairly. Once you realize that
> you may need to service a mix of these types of applications, you are once again
> forced to adopt another model. This is hardly a hack. This is the real world.
> Now then, *my* implemention is somewhat of a hack, but simply because the
> information was not readily available. Keep in mind, this is one such reason
> why some OS's provide facilities for process afinity which would simply allow
> a process to run, for example, on the first 4 processors and leave the other
> four free reguardless of how many children or threads the parent makes.
>
> I spelled out, using a real world situation why such a mechanism needs to exist.
> You simply said it's a hack and violates some made up "tenet". Please tell me
> how you would solve it. Keep in mind this was on a project that was three years
> and 2-million overdue and long delays of yet *another* complex system would
> more than likely result in the rolling of your head and/or arse. Even without
> such constraints, I'd like to see your magical solution. Saying the concept
> is a hack, which is clearly required, without any supportive evidence seems
> a pretty cheap way out to me.
Hitting a raw nerve, eh --I apologize. You indeed spelled out why you needed
such a function using current technology. I'm merely pointing out that you're
doing the equivalent of having different file systems on 5.25" and 8" disks,
as good old Flex did, at the level of processors and scheduling. When you're
faced with the reality of solving a problem using a particular set of tools,
you might not think of fixing the tools before tackling the job, but given the
time and cost overruns you mention, it might not have been a totally useless
idea to consider upgrading the tools...
--
Stefaan
--
How's it supposed to get the respect of management if you've got just
one guy working on the project? It's much more impressive to have a
battery of programmers slaving away. -- Jeffrey Hobbs (comp.lang.tcl)
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: How to get a number of processors
Crossposted-To: comp.os.linux.development.apps
Date: Mon, 7 May 2001 23:27:18 +0200
In article <[EMAIL PROTECTED]>,
John Beardmore <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]>, Stefaan A Eeckels
> <[EMAIL PROTECTED]> writes
>
>>Maybe the OS should provide a service to ensure that certain
>>processes get a minimum of CPU time. The approach you describe
>>is a hack, and goes completely against the basic Unix concept
>>of hiding the hardware differences and specifics from the
>>applications.
>
> Guaranteeing resources to processes may be a good tool, but it isn't an
> alternative to knowing how many threads to create for a big crunching
> job. For that, you still need to know the number of available
> processors.
Why not tell the OS you want the number of parallel instances
optimal for the kit and job mix on hand?
--
Stefaan
--
How's it supposed to get the respect of management if you've got just
one guy working on the project? It's much more impressive to have a
battery of programmers slaving away. -- Jeffrey Hobbs (comp.lang.tcl)
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: file read problem
Date: Mon, 07 May 2001 21:59:02 GMT
In article <[EMAIL PROTECTED]>, yan zhang wrote:
>I have a function called read_file_to_string. In this function, I tried
>to use file->f_op->read to read a text file from local directory. I can
>open it without problem but when I read it, linux system crashed.
[-]
What is file to start with as I'm more than pretty sure there's
no Unix structure which would make something named f_op public.
Ta',
Juergen
--
\ Real name : Juergen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Driver functions after a Segmentation Error
Date: Mon, 07 May 2001 22:03:37 -0000
In article <LEEJ6.9530$[EMAIL PROTECTED]>,
Norm Dresner <[EMAIL PROTECTED]> wrote:
>There were two errors in the module, the first an attempted read access of
>user-space -- copy_from_user() -- and the second a write back to the same
>address. Both used the same (erroneous) pointer. I don't see how the
>second could have trashed something because if its address was seg-faulting,
>the first access would have too.
I was afraid you'd say something like that. All I can say now is that
when I was testing drivers I found the kernel to be unstable after a
driver seg faulted. While I hated to reboot it turned out to be a wise
thing to do.
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: where do I see dprintk messages
Date: Mon, 07 May 2001 22:06:45 -0000
In article <YHEJ6.5185$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>I am using function calls from mm/memory.c. What do I have to do to see the
>dprintk messages. I see my printk messages in /var/log/messages. Is there
>special compile time flag I have to use and where should I expect them.
You see them where you've told /etc/syslog.conf to put
them or on the console if they are high enough priority. See
/usr/src/linux/Documentation/proc.txt for information on setting the
console printk priority levels.
--
http://www.spinics.net/linux
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
