Linux-Development-Sys Digest #76, Volume #8 Sat, 12 Aug 00 05:13:07 EDT
Contents:
Re: Problem including <limits.h> (Paul Kimoto)
Re: printk and EXPORT_SYMBOL in a MODULE ("Chris")
Re: Problem including <limits.h> (Kaz Kylheku)
GUI-Kernel Integration or Lack Thereof (Christopher Browne)
all threads in a process share the same pid? ("Peter Huang")
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? (Kaz Kylheku)
Re: /proc/mtrr is empty (jwk)
How to get clear sound from /dev/dsp(/dev/audio) (Bomshik Kim)
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Crossposted-To: comp.os.linux.setup
Subject: Re: Problem including <limits.h>
Date: 11 Aug 2000 19:47:49 -0500
Reply-To: [EMAIL PROTECTED]
[Text slightly reorganized.]
In article <[EMAIL PROTECTED]>, Andrew Jaffe wrote:
> [EMAIL PROTECTED] (Tony Seward) writes:
>> I thought that I had seen somewhere on the kernel list
>> that users should not have to have the kernel headers on their machine
>> in order to compile normal programs (i.e. programs that don't interact
>> directly with the kernel). So, I'm wondering if I'm remembering this
>> wrong or if there should be headers with glibc or if their should be
>> another RPM.
Sometimes user programs need to have information agreeing with what the
kernel uses; thus the existence of <linux/*.h> and <asm/*.h> files. In
the old days, you (the programmer) would just use the files in
/usr/src/linux/include/linux and /usr/src/linux/include/asm for this
purpose; hence the traditional symbolic links from /usr/include to those
directories.
After a while, the kernel programmers became weary of maintaining header
files for user programs. Since glibc2, it has been possible to apply the
rule "do not directly include <linux/*.h> or <asm/*h> files in user
programs". The glibc header files do refer to them when necessary, though,
so they are included indirectly.
It is still a problem that the kernel programmers like to make changes to
the kernel header files and would rather not worry about the needs of those
who write user programs: it is rare that a user program cares about the
kind of details that may change in everyday kernel releases. Thus many
(although not all) argue that /usr/include/linux and /usr/include/asm
should not be symbolic links into the kernel-source-code-of-the-day, but
rather be regular directories containing headers from some stable kernel.
As far as I know, only Debian (and derivatives) does this; these files are
part of the libc development package.
> I have a related problem. I have RH6.1, but I recently upgraded to
> kernel 2.2.16, using the instructions from the HOWTO (as well as all
> other recommended upgrades)
>
> Now, when I try to compile anything complicated (e.g. the kernel itself,
> or xemacs), I get error messages like
>
> In file included from /usr/include/errno.h:36,
> from <whatever>
> /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory
>
> that is, linux/errno.h doesn't exist (nor does any other linux/*.h that
> various *.h files try to include)
>
> I have tried getting the latest glibc libraries and headers, to no avail.
For the sake of user programs, (as I wrote above) you probably need
symbolic links
/usr/include/linux -> /usr/src/linux/include/linux
/usr/include/asm -> /usr/src/linux/include/asm
This doesn't explain the problem with compiling the kernel, though; I think
that the gcc commands request the "current" #include files (those in the
kernel source tree itself) via the appropriate -I flag.
--
Paul Kimoto
Disclaimer: Other than explicit citations of URLs, hyperlinks appearing
in this article have been inserted without the permission of the author.
------------------------------
From: "Chris" <[EMAIL PROTECTED]>
Subject: Re: printk and EXPORT_SYMBOL in a MODULE
Date: Fri, 11 Aug 2000 17:36:35 -0700
I just figured this out today...
In exactly one module, include the line
#define EXPORT_SYMTAB
Then in the same module, export your symbols using the macro
EXPORT_SYMBOL_NOVERS(MyFunction)
I was then able to get two modules talking to each other via exported
functions.
That's all there is to it (for kernel 2.2+). I haven't figured out how to
use the versioning version yet...
Chris
"Brian Horton" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> kernel newbie here... I'm trying to build a kernel module (that I'll be
> loading via insmod) and want it to export a symbol (via EXPORT_SYMBOL).
> I compile the code w/ -DMODULE -DEXPORT_SYMTAB and it compiles fine.
> But, when I insmod it fails w/ unresolved on symbol 'printk'. Sure
> enough, my kernel doesn't have 'printk', it has:
>
> # cat /proc/ksyms|grep printk
> c0113e2e printk_R1b7d4074
>
> So how do I get printk and EXPORT_SYMBOL at the same time? What am I
> doing wrong? Some other flag or -D that I need? Or can Modules not
> export symbols?
>
> thx.bri.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.setup
Subject: Re: Problem including <limits.h>
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Aug 2000 01:05:43 GMT
On 11 Aug 2000 14:53:13 -0700, Andrew Jaffe <[EMAIL PROTECTED]> wrote:
>In file included from /usr/include/errno.h:36,
> from <whatever>
>/usr/include/bits/errno.h:25: linux/errno.h: No such file or directory
You have broken /usr/include/linux and /usr/include/asm symbolic links.
Perhaps you have rooted your kernel source tree in a path other
than /usr/src/linux.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: GUI-Kernel Integration or Lack Thereof
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Aug 2000 02:12:08 GMT
Centuries ago, Nostradamus foresaw a time when [EMAIL PROTECTED]
would say:
>Nathaniel Jay Lee <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Ah, let the people be heard!
>>
>> This is the stuff I find scary. I don't mind the idea of 'modularizing'
>> the graphical interface into the kernel (as I believe some of the early
>> efforts are underway to do so), just don't make it something that is
>> *forced* on me.
>
>Now implementing the frame buffer in the kernel was a good idea since
>it can present a more or less uniform method of handling the
>graphical screen across most Linux platforms. However, very much
>more graphics support in the kernel is not good. The more of the GUI
>that is in the kernel, the more the systems stability could be
>compromised.
This is an example of a situation where there is just _ample_
opportunity for flaming by the clueless, but where there's
considerable ambiguity even for those that _do_ have a clue.
Consider:
Probably 3 years ago, the GGI folks proposed pushing a whole _LOT_ of
graphics stuff into the kernel.
They were rightly lambasted by the kernel folk for a number of
reasons:
1. They were proposing embedding a whole lot of functionality into the
kernel "KGI" portion of GGI.
Bad, for all the robustness reasons, as well as because this makes
the kernel bigger, and thus means that less stuff can get swapped
out.
2. They assumed that their code base needed to be integrated in "right
now, because we're cool dudes, and this needs to be done."
Which isn't how things are done. ReiserFS has been waiting for
_months_ after pushing hard for entry into the kernel at the start
of this year.
The GGI code base _wasn't nearly mature enough_ at the time.
3. The GGI code base was, at the time, _pretty bad code_. They were
doing major surgery on the console code, and a fair bit of it was
definitely not pretty code.
If it's not readable, and if it's not compatible with the many
other architectures that were of some importance even then, that
doesn't fly.
However, it wasn't _all_ bad, and there are some interesting
counterobservations.
4. They _did_ have things split out into "kernel stuff" and "user mode
stuff." It _wasn't_ a matter of having the whole "GUI in the
kernel."
The Framebuffer code that has since gotten integrated into the
kernel may be a bit less than the GGI folk had hoped for, but I
expect not _dramatically_ so.
5. Didn'tcha know that there _ALREADY WAS_ GUI code in the kernel?
One of the major areas of "surgery" in GGI related to changes to
the console code.
Remember, what is console support, other than a (perhaps
rudimentary) GUI?
-> It involves drawing stuff on the screen;
-> It includes a font renderer and a font manager;
-> It even includes a "higher level library," in the form of
emulation of "some VT100 superset."
It may only get _used_ to splatter text on the screen, but that
doesn't make it any the less a GUI of sorts.
<http://howto.tucows.com/LDP/HOWTO/Framebuffer-HOWTO-3.html>
describes how the Framebuffer concept was downright _useful_ in
unifying the way consoles are accessed on different platforms;
there had been quite different code on IA-32 as compared
particularly to m68k.
6. It seems to me that putting some set of Useful Hardware
Abstractions into the kernel _IS_ a legitimate thing to do.
Having the kernel provide a "structured" way to push commands to
the graphics hardware rather than having "user world" manage the
hardware as typically happens with X seems like a reasonable idea.
The Linux Framebuffer provides this, and seems to be a pretty
appropriate abstraction to have in the kernel. See:
<http://howto.tucows.com/LDP/HOWTO/Framebuffer-HOWTO.html>
<http://go.163.com/~bricks/linux/program/framebuffer.html>
I could see going _somewhat_ further in having _some_ more
structure provided. X is certainly _NOT_ implemented in a manner in
keeping with Unix Philosophy in that it does not export any of its
hierarchy as a set of "filesystem-like" things.
The Plan 9 window manger, rio, provides a hierarchical
filesystem-based way of accessing windows.
<http://plan9.bell-labs.com/magic/man2html/1/rio> Whether or not
this ought to be in the kernel is certainly a legitimate question.
On the one hand, I agree that anyone seriously considering the kind of
GUI integration that Windows NT has for Linux has _got_ to be smoking
crack, particularly with the degree of interest in Linux for _EMBEDDED
COMPUTING_, where there's typically NO GRAPHICAL DEVICE AT ALL.
On the other hand, baldly assessing _all_ changes that have _anything_
to do with graphics that happen in conjunction with the kernel as
being diseased _also_ indicates that the "assessor" has smoked too
much crack, because it just isn't necessarily so.
The thing that _is_ seriously "diseased" is the quality of the
interfacing of graphical devices to PCs. The recent flamewars that
have erupted surrounding the ability to, in a few instructions, nuke
partition tables on IDE drives, provide no new news of "lack of
robustness of PCs." The fact that SVGA boards sit on PCI and AGP
buses with intense access to RAM means that they have a _tremendous_
ability to LOUSE THINGS UP if they aren't carefully used.
If a SVGA command queue can be managed by a little portion of the
kernel, thus making "managed access" the norm rather than the
exception, that can at least _help_.
Thus:
- Windowing system in kernel: BAD.
- Framebuffer in kernel: Probably good.
- Font manager in kernel: BAD.
- Tagged SVGA command queue, parallelling tagged SCSI command queue:
Probably a VERY good thing.
>The computer rag that I was talking about was sitting with the
>newspaper and magazines at the barber shop. I didn't pay any
>attention to it at first, but the barber did. He didn't read the
>article but just took the headline on the cover as his issue of the
>day. The headline was as well as I can remember, "Linux says 'Get
>lost Geeks and hello *real* people' --Linux take learns lessons from
>Microsoft and accepts Windows style full GUI intergration".
Keep in mind that the quality of other aspects of news reporting are
probably often of similar quality...
>So I read the two page article and found it to be nothing more than
>an amplification of the USENET thread that had participated in. The
>author accepted everything that was suggested by the otherside of the
>thread. The opinions and observations of myself and others that had
>the same opinions and views were dismissed as the "foolish crack
>dreams of the Geeks who ruined Linux since the 1960's". The article
>never did admit the source of the information within it, but I knew
>it was not a coincidence. It contained a few unattributed but exact
>quotations from my postings and others in that thread.
... And if the code is written by the "Geeks who ruined Linux since
the 1960's", then _that_ trumps any blathering that reached your
newspaper.
See obligatory Linus Torvalds quote below. :-)
--
(concatenate 'string "cbbrowne" "@" "ntlug.org")
<http://www.ntlug.org/~cbbrowne/linux.html>
"The Linux philosophy is laugh in the face of danger. Oops. Wrong
One. 'Do it yourself.' That's it." -- Linus Torvalds
------------------------------
From: "Peter Huang" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: all threads in a process share the same pid?
Date: Fri, 11 Aug 2000 22:30:39 -0700
Hi all
How do I get the pid of the current running process. Also, does each posix
thread within a single process has its own pid or just its own pthread_d
value but share the same pid.
Thanks.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Sat, 12 Aug 2000 05:41:37 GMT
In comp.os.linux.development.apps Peter Huang <[EMAIL PROTECTED]> wrote:
> How do I get the pid of the current running process. Also, does each posix
> thread within a single process has its own pid or just its own pthread_d
> value but share the same pid.
Linux doesn't support Posix threads. Each thread _should_ have the
same pid, but instead they're actual processes with their own.
As to finding the pid, man 2 getpid.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
From: [EMAIL PROTECTED]
Date: Sat, 12 Aug 2000 07:15:11 GMT
[EMAIL PROTECTED] writes:
> > How do I get the pid of the current running process. Also, does each posix
> > thread within a single process has its own pid or just its own pthread_d
> > value but share the same pid.
> Linux doesn't support Posix threads. Each thread _should_ have the
> same pid, but instead they're actual processes with their own.
It doesn't?
What's pthreads, then?
> As to finding the pid, man 2 getpid.
--
Eric McCoy ([EMAIL PROTECTED])
"misfortune, n. The kind of fortune that never misses."
- Ambrose Bierce, The Devil's Dictionary
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
From: [EMAIL PROTECTED]
Date: Sat, 12 Aug 2000 07:16:05 GMT
"Peter Huang" <[EMAIL PROTECTED]> writes:
> Hi all
>
> How do I get the pid of the current running process.
getpid()
> Also, does each posix thread within a single process has its own pid
> or just its own pthread_d value but share the same pid.
On Linux, each thread has a different pid as well as a different tid.
You can get the former using getpid(), the latter using pthread_self()
(or somesuch).
--
Eric McCoy ([EMAIL PROTECTED])
"corsair, n. A politician of the seas."
- Ambrose Bierce, The Devil's Dictionary
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Aug 2000 07:17:32 GMT
On Sat, 12 Aug 2000 07:15:11 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>What's pthreads, then?
An unofficial nickname for POSIX-like threads everywhere.
------------------------------
From: [EMAIL PROTECTED] (jwk)
Subject: Re: /proc/mtrr is empty
Date: 12 Aug 2000 07:44:07 GMT
Reply-To: [EMAIL PROTECTED]
On 11 Aug 2000 21:42:29 GMT, Karl Stephenson-M�ller
<[EMAIL PROTECTED]> wrote:
>I have MTRR support compiled in the kernel and there is a /proc/mtrr file.
>The problem is that it contains nothing. I am running RedHat 6.2 on a K6-2 300
>(stepping 12), Voodoo3 3000 AGP, FIC VA-503+ mb.
>
>[karl@boye karl]$ cat /proc/mtrr
>[karl@boye karl]$
>
>When the 3dfx device driver module (which is supposed to enable MTRR support)
>is loaded:
>
>[karl@boye karl]$ cat /proc/mtrr
>reg00: base=0xe4000000 (3648MB), size= 16MB: write-combining, count=1
>[karl@boye karl]$
>
>I've learned that there should also be at least one write-back register. Is
>this correct? I get the same result using both RedHat's kernel 2.2.14-5.0 and
>2.2.16 from kernel.org. Help would be appreciated.
>
/proc/mtrr is empty when nothing is set. After the 3dfx module sets a
value, it is not empty anymore. My /proc/mtrr looks like this:
reg00: base=0x00000000 ( 0MB), size= 256MB: write-back, count=1
reg01: base=0xe8000000 (3712MB), size= 32MB: write-combining, count=3
this is on a P-III. The first one seems to be main memory, I'm not sure
if it is necessary, but you could set it yourself.
I don't think there is something to worry about!
Jurriaan
--
If something was not wrong things would not be right.
Sergeant Ortega - Zorro
GNU/Linux 2.2.17pre16 SMP 4 users load av: 0.47 0.17 0.10
------------------------------
From: Bomshik Kim <[EMAIL PROTECTED]>
Subject: How to get clear sound from /dev/dsp(/dev/audio)
Date: Sat, 12 Aug 2000 17:13:53 +0900
Hello~
I want to know "How to get clear sound from /dev/dsp".
I use the ioctl function in order to get 16bit signed
integer, 8KHz sampled sound.
But the sound(voice) gotten from /dev/dsp (by opening /dev/dsp and
reading that file_descriptor(fd) ) is not clear. There is some noise
(or scratch sound) in voice.(I think that it is not
a problem of sound-card/microphone)
I tried to open /dev/dsp with O_RDONLY and read the fd
for some seconds to get voice, saved the voice data in memory.
After that, I closed the fd, reopen /dev/dsp with
O_WRONLY, and write the saved voice data to a new file-descriptor.
In this manner, I didn't hear scratch-sound.
But opening /dev/dsp with O_RDWR, and read/write voice data make
some scratch sound.
open O_RDONLY -> read sound -> close ->
open O_WDONLY -> write sound -> close -> open O_RDONLY -> ...
It means that a sound-block read from sound_card
(not voice data of some duration) is played back as soon as possible
Repeating this sequence also makes scratch sound which is the bigger
scratch sound than the sound of O_RDWR mode.
I want to open /dev/dsp O_RDWR, set up the file descriptor
to full duplex mode, and read/write the fd without scrath sound.
Is it impossible to reduce scratch sound in opening /dev/dsp
withO_RDWR mode ?
Thank you for reading...
BS Kim
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Sat, 12 Aug 2000 08:54:06 GMT
In comp.os.linux.development.apps [EMAIL PROTECTED] wrote:
> It doesn't?
> What's pthreads, then?
They're a half implementation of the standard. Take a look at the
following url for a list of features they don't support.
http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=552966193&fmt=text
And yes, this is a sore subject for me. :)
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
