Linux-Development-Sys Digest #87, Volume #7 Sun, 22 Aug 99 19:14:05 EDT
Contents:
Lirc and Kwintv (Berco van Gool)
Re: Linux - Memory model / protection scheme (Ulrich Weigand)
Re: Why so inefficient source RPM's ?? (Bill Anderson)
Re: strcmp in kernel (Peter Pointner)
Re: Autoscan, Autoconf, and Automake - HOWTO? (Michael Schuerig)
Re: Linux's faults (David Wragg)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Jonas Utterstrom)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Jonas Utterstrom)
Re: threads (Mark Hahn)
Re: remap? >> hdc: [DM6:DDO] [remap +63] [524/64/63] hdc1 hdc2 hdc3 (Chris Butler)
Re: [kernel] how to measure running time in nanosecond? (Mark Hahn)
Linux threads and the MAX parameter ("Donald Setlur")
Re: SCSI Tekram DC-390F on linux 2.0.36 (or 2.2.11) (Michael Meissner)
Re: Calling a BIOS interrupt (Chris Butler)
Writing to boot sector ("Benjamin S. Vera-Tudela")
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Josh Stern)
Re: 497.2 days ought to be enough for everybody (H. Peter Anvin)
Re: "current" while DMA (Yung-Hsiang Lu)
----------------------------------------------------------------------------
From: Berco van Gool <[EMAIL PROTECTED]>
Subject: Lirc and Kwintv
Date: Sun, 22 Aug 1999 19:30:17 +0200
Hello,
Since several weeks I have an Irman. I use the Irman Library and the
software from the Lirc project. I have configured Lirc and the test
software from Lirc works (irw) good. But if I want to connect kwintv (a
television program for Linux) to Lirc. It don't workcorrectly.
If I use the Infrared remote control setup from Kwintv and I press some
remote control buttons every button generates the same very long code,
but the button name is generated good.
I can't use a remote control for kwintv. Can you tell me what I have to
do?
Is it a bug or a configuration problem?
I hope you can help me.
Greetings Berco.
------------------------------
From: [EMAIL PROTECTED] (Ulrich Weigand)
Subject: Re: Linux - Memory model / protection scheme
Date: 22 Aug 1999 20:39:18 +0200
Todd Knarr <[EMAIL PROTECTED]> writes:
>True, but you can only generate holes with a 4MB granularity using the
>page table directory. In the page table itself, absent pages require
>an entry marked "not present", so holes in the middle of a range of
>addresses don't reduce the number of entries needed. Looking at the
>reference manual it looks like you need to map in 4MB increments for
>efficiency, ie. you need a full 1024-entry page table even if you're
>only actually mapping 1MB of the space.
Well, but a full 1024-entry page table is just one page in size
(1024 entries * 4 bytes/entry = 4 KB = 1 page).
You can't use smaller amounts of memory anyway at this level ...
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.misc,linux.redhat.rpm
Subject: Re: Why so inefficient source RPM's ??
Date: Sun, 22 Aug 1999 13:23:15 -0600
Piercarlo Grandi wrote:
> I'd love too to have SRPMSes by default not incorporate the original
> source archive, and download it separately; this can even be done, and
> has been done, for packages whose source cannot be redistributed by
> RedHat. But the default is still what suits the RedHat way of doing
> things.
A better way is for the maintainer to distribute a tarball that contains
the spec file. Then you can do:
rpm -ta foo.tar.gz
and get an SRPM and an RPM of teh tarball built.
This would be quite nice for the no-source-pathces-only type of tarball.
RPM has far larger issues than the maintanier of an app not making the
range or rpms available.
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: strcmp in kernel
Date: Sun, 22 Aug 1999 08:09:00 GMT
[EMAIL PROTECTED] wrote:
> I can't use strcmp in my device driver even if i include
> <linux/string.h>. The compiler says implicit declaratiion
> of function.
> How do i use strcmp a device driver?
strcmp might be defined as inline function. Use at least
gcc -O when compiling your driver to make the inline functions
work.
Peter
------------------------------
From: [EMAIL PROTECTED] (Michael Schuerig)
Subject: Re: Autoscan, Autoconf, and Automake - HOWTO?
Date: Sun, 22 Aug 1999 21:10:44 +0200
Stephen Torri <[EMAIL PROTECTED]> wrote:
> I have some .cpp files I got off the web. I thought I would create a
> Makefile. There are only three files so I thought it would be an easy
> start for a novice. Is there a HOWTO or a website which talks about how
> to use these programs to create the configure and Makefile?
It's an option to read the docs that come with autoconf and automake,
but before you do that, have a look at autotools by Eleftherios
Gkioulekas. The package includes a tutorial for the GNU build system
including automake, autoconf, libtool.
Michael
--
Michael Schuerig
mailto:[EMAIL PROTECTED]
http://www.schuerig.de/michael/
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: Linux's faults
Date: 22 Aug 1999 13:55:08 +0000
XuYifeng <[EMAIL PROTECTED]> writes:
> If I am right, Linux has design problem for Large server application,
> Larger server always has many socket and file handles opened at same
> time, think about its fd_set structure for select() functions, it only
> allow 1024 socket handles opened same time, problem is both socket
> handle and file handle shares same file descriptor table, if there is
> lots of file opened at same time, for examples, 1024 files opened,
> because Linux's fd_set structure uses bitmap structure, you event can
> not open a socket for select()! because it's fileno is 1025, there is
> no way to put this fd into fd_set structure.
Then use a 2.2 kernel and poll ("man 2 poll") instead of select.
> by the way, Linux has too many limits.
A few years ago, it had many limits. Now, almost all of them are gone,
or at least dynamically adjustable. For example, in recent 2.3
kernels, there is no kernel limit at all on the number of
files/sockets a process can have open. All operating systems have
problems, the nice thing about Linux is they get fixed quickly, and if
they don't you can fix them yourself.
David Wragg
------------------------------
From: Jonas Utterstrom <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
Date: Sun, 22 Aug 1999 20:44:01 GMT
In article <9uWv3.359$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Josh Stern) wrote:
>
> I really wonder about the merits of this generalization. In the
> case of Mozilla, it uses a lot of shared libraries but those are
> not built into the executable, which is extremely large to begin
> with. Part of the reason for this is undoubtably due to the fact
> that it is a very full-featured program, and part of the reason
> is because it coded in a very careless and sloppy way. Also note
Badmouthing Mozilla developers is not a good way of explaining the size
of Mozilla. One of the reasons we don't have a new version of Mozilla is
because of their decision to rewrite the sloppy code.
> that for both C++ shared libraries and objects, the size of the
> files on disk is not a good indication of the amount of run-time
> resources that they use. It would be better to compile the library
> as both static and shared, and then measure things like how
> long the program takes to load and what 'top' says about its
> size when it is running (multiple processes if that is relevant
> to the application). Looking at the size of the files on
> disk is primarily relevant to concerns about disk usage.
>
If a library is twice as big, it takes longer to load. I do not claim
that I know how things are organized in memory. But there must be some
way to perform dynamic linking, and if this symbol-table is twice as
big, it probably also uses more memory. But that is only my gut feeling,
I have no proof.
I guess I have to read the ELF specifications to discuss this further.
;)
/Jonas U
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Jonas Utterstrom <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
Date: Sun, 22 Aug 1999 20:25:52 GMT
In article <7ppbt4$iqb$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Philip Armstrong) wrote:
> >As I have said in another thread, exporting chosen functions is
possible
> >if you are willing to use a development version of ld. But my advice
is
> >to live with the code-bloat until a stable version arrives.
>
> And pester Ulrich Drepper + co to get it working properly in the
> stable releases :)
>
Of course it won't do no harm testing it before it is stable of course.
I was thinking that people leaving Windows shouldn't have to deal with
alpha code, it might turn them off. ;)
> >You don't need to export functions from shared libraries in Linux,
they
> >are all exported (except from static functions). But if you have
equal
> >internal functions in two different shared libraries, you're out of
> >luck.
>
> I'll have to try this, but isn't this is only a problem if you want to
> call those functions in your code? Presumably internal (private)
> functions called from code in the same libary don't need the symbol
> table entry, as they can be called directly.
>
> Anyway, this is getting well beyond my secure base of knowledge. I'll
> write some test code and see what happens...
>
You got me uncertain so I made two shared libraries. No linking
problems, but the function from the first linked library was always
used.
/Jonas U
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: threads
Date: 22 Aug 1999 21:12:10 GMT
> I don't know how this works on Linux, but on Windows, switching threads
> requires the CPU registers to be saved and reloaded. A process switch
> requires the memory management unit to be reconfigured as well.
don't make it seem larger than it is: the current kernel has all sorts
of nice tricks to make switches optimally lazy. this comes FAR short
of "reconfiguring" the MMU.
> my understanding of the hardware goes, Linux must be similar. Even if
> process context switches are cheap, they can't be as cheap as thread context
> switches, unless Threads are poorly implemented.
this doesn't make sense, though. there will be a user-kernel context
switch in any real thread implementation, and it hardly matters whether
the kernel switches back to one set of registers or another. so-called
user-level thread libraries (more correctly called co-routines) avoid
this small overhead, but suffer BADLY in code robustness and performance.
the robustness problem is simply that they must hack around the blocking
nature of all IO. the performance problem is that when a coroutine takes
a page fault, the other pseudo-threads are hung as well...
in short: Linux does threads right.
regards, mark hahn.
--
operator may differ from spokesperson. [EMAIL PROTECTED]
http://java.mcmaster.ca/~hahn
------------------------------
From: [EMAIL PROTECTED] (Chris Butler)
Subject: Re: remap? >> hdc: [DM6:DDO] [remap +63] [524/64/63] hdc1 hdc2 hdc3
Date: 22 Aug 1999 21:44:01 +0100
[comp.os.linux.development.system - Sat, 21 Aug 1999 01:51:00 +0000] * Nigel wrote *
> But during the partition check the following is displayed
> Partition check:
> hda: hda1 hda2 hda3
> hdc: [DM6:DDO] [remap +63] [524/64/63] hdc1 hdc2 hdc3
This looks like you have Ontrack DiskManager installed (version 6).
> I have tried the drive in different Linux machines and this always
> happens, I have done a low level IDE format from BIOS but nothing seems
> to stop the remap at boot time.
> What/ why is this remap happening?
The easiest way to stop it is to pass "hdc=cyl,head,sect" on the
commandline to the kernel (via an append line in /etc/lilo.conf for
example). This forces the kernel to not do an auto-probe of the values,
and will stop it re-mapping.
--
Chris Butler
<[EMAIL PROTECTED]>
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: [kernel] how to measure running time in nanosecond?
Date: 22 Aug 1999 21:19:40 GMT
> Use Linux-2.2.11 and then add Ulrich Windl's 'NANO' patches. You can
there's no reason to use any particular kernel or patches. the following
provides ultimate resolution; calibrating it (finding secondsPerTick)
is pretty trivial:
typedef unsigned long long u64;
inline u64
rdtsc() {
u64 clock;
__asm__ __volatile__("rdtsc" : "=A" (clock));
return clock;
}
------------------------------
From: "Donald Setlur" <[EMAIL PROTECTED]>
Subject: Linux threads and the MAX parameter
Date: 23 Aug 1999 08:04:48 GMT
Hi folks,
I have an elementary Question on threads.
I am using the using pthreads_create call to issue a bunch of threads
which are all simultaneously active.
I am experiencing problems with creating more than 251 concurrent threads
(probably the limit being 255 by defaullt).
I wonder if ya'all know of some tricks to increase this number.
I am using Redhat 5.* for a OS. Please let me know if there is some more
details I need to supply to get an answer. Thanks in advance,
Donald
------------------------------
Crossposted-To: comp.os.linux.hardware
Subject: Re: SCSI Tekram DC-390F on linux 2.0.36 (or 2.2.11)
From: Michael Meissner <[EMAIL PROTECTED]>
Date: 22 Aug 1999 17:17:41 -0400
Dorin-Ioan MARINCA <[EMAIL PROTECTED]> writes:
> Hi!
>
> What I must check on "make -xconfig" windows to create an linux kernel
> (2.0.36 or 2.2.10/11) which supports an SCSI controller Tekram DC-390F?
On my 2.2.10 system, I have:
CONFIG_SCSI_NCR53C8XX=y
CONFIG_SCSI_SYM53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
# CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
On earlier systems, the SYM53C8XX question won't be asked and probably some
others.
> and
>
> can anyone give me some hints (links to docs/HOWTOs/keywords) on how to
> make an soft RAID 0/5 on some disks connected to above card? ...
Note, the raid tools shipped with RedHat 6.0 aren't compatible with the raid
support in generic 2.2.x (RedHat uses a patch to go to a newer revision of the
raid support, but its incompatible with the old raid support).
--
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: [EMAIL PROTECTED] phone: 978-486-9304 fax: 978-692-4482
------------------------------
From: [EMAIL PROTECTED] (Chris Butler)
Subject: Re: Calling a BIOS interrupt
Date: 22 Aug 1999 21:32:25 +0100
[comp.os.linux.development.system - Fri, 20 Aug 1999 01:38:05 GMT]
* Bartosz wrote *
> Chris Butler wrote:
>> It gets all the information it needs from the BIOS at boot time (eg, HD
>> information, etc), before switching to protected mode.
> Are you sure about that HD information? I think the kernel ignores what
> BIOS says about HD. I once used to change disk drives without setting
> BIOS appropriately, and Linux somehow identified disk geometry etc.
OK. Instead of basing my messages on vague recollections of what I thought
I'd heard on linux-kernel a while back, I UTSL. :-)
It seems, from arch/i386/boot/setup.S, that it gets the following from the
BIOS at boot time: (from the comments)
* memory size
* hd0 data
* hd1 data (including whether there is a hd1 or not)
* existance of a MCA bus
* " " " PS/2 mouse
(if CONFIG_APM is defined)
* " " " APM BIOS
* the entry point, etc, for calling APM functions from 32-bit mode
After this lot, it goes into protected mode.
So, it looks like it _does_ get HD info from the BIOS. Although it DOES
also probe the IDE bus directly when the IDE driver initialises. The
reason for doing it both ways can probably be explained by a kernel
hacker :-)
--
Chris Butler
<[EMAIL PROTECTED]>
------------------------------
From: "Benjamin S. Vera-Tudela" <[EMAIL PROTECTED]>
Subject: Writing to boot sector
Date: Sun, 22 Aug 1999 21:55:08 GMT
Hi all. .... I am new to this newsgroup, some please welcome me!!! :)
I have a question: I have never written device drivers and other cool stuff
under linux. I run RH 5.2 and will like to write to the boot sector of a
floppy some stuff (e.g. a buffer of data). I have opened /dev/fd0 using the
open system call but I dont know how to write to the boot sector of the
floppy. I though I could use the write system call, or ioctl (which I have
never played with) so I need some help. Anybody???
Thanks
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
From: [EMAIL PROTECTED] (Josh Stern)
Date: Sun, 22 Aug 1999 22:00:23 GMT
Jonas Utterstrom <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Josh Stern) wrote:
>> I really wonder about the merits of this generalization. In the
>> case of Mozilla, it uses a lot of shared libraries but those are
>> not built into the executable, which is extremely large to begin
>> with. Part of the reason for this is undoubtably due to the fact
>> that it is a very full-featured program, and part of the reason
>> is because it coded in a very careless and sloppy way. Also note
>Badmouthing Mozilla developers is not a good way of explaining the size
>of Mozilla.
What I wrote is not tantamount to bad-mouthing Mozilla developers.
They may have had very important reasons (e.g. time pressure)
for coding Netscape in a careless and sloppy way. My hypothesis
of why Netscape is so big is a) it has a lot of features,
and b) it was coded with the priority of minimizing time to market
for a complex cross-platform app. Your "explanation" of why
the Netscape executable is so big - because C++ shared libraries
are much bigger than C shared libraries - was nonsensical bullshit.
>One of the reasons we don't have a new version of Mozilla is
>because of their decision to rewrite the sloppy code.
Indeed.
>> that for both C++ shared libraries and objects, the size of the
>> files on disk is not a good indication of the amount of run-time
>> resources that they use. It would be better to compile the library
>> as both static and shared, and then measure things like how
>> long the program takes to load and what 'top' says about its
>> size when it is running (multiple processes if that is relevant
>> to the application). Looking at the size of the files on
>> disk is primarily relevant to concerns about disk usage.
>If a library is twice as big, it takes longer to load.
The run time performance depends on what gets loaded when.
On Linux, resolution of references from a shared library
is 'lazy' by default, meaning that they are resolved as
needed during execution, so a particular module of code
that is not used is likely to remain un-read on disk.
Try 'man dlopen'. Or better yet, just adopt an empirical
approach to the question and experiment as I suggested
previously.
Also, for C++ libraries, code related to exception
handling is likely to be stored in different sections
and not read unless an exception gets thrown.
>I do not claim
>that I know how things are organized in memory. But there must be some
>way to perform dynamic linking, and if this symbol-table is twice as
>big, it probably also uses more memory. But that is only my gut feeling,
>I have no proof.
>I guess I have to read the ELF specifications to discuss this further.
>;)
Yes, and do the easy experiment with your own applications to
see what the effects of shared libraries and C++ really are. I
think you will be pleasantly surprised.
- Josh
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: 497.2 days ought to be enough for everybody
Date: 22 Aug 1999 22:00:04 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <7pmrri$po4$[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED] (Florian Kirstein)
In newsgroup: comp.os.linux.development.system
>
> Hi,
>
> OK, here I am again. My third box is getting near the magical limit of the
> Jiffies and will roll over the 497.2 day uptime limit in a few days. My
> problem: my first box survived this, my second one (I can't be 100% sure
> but I heard others had this, too) crashed. So: are there any kernel hackers
> with a deeper insight, who know where a rollover of the jiffies counter
> could result in a crash and under which conditions this can happen? It's a
> kernel 2.0.33 - the one that crashed was 2.0.32, the one that survived 2.0.18.
> I really don't want to reboot my machine, because then I couln't laugh about
> Win95 crashing after 49.7 days any more :)
>
Jiffies rollover can cause a crash in incorrectly written kernel
code; usually a device driver. Most device drivers should use the
properly blessed windowing algorithm (e.g. (now - then) < threshold)
but if they're doing bad stuff (e.g. now > then) then it will break.
Whether or not that particular breakage will cause a crash is yet
another issue; however, it is *very* important that everyone who
writes kernel code that uses jiffies make their code rollover-safe.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
From: [EMAIL PROTECTED] (Yung-Hsiang Lu)
Subject: Re: "current" while DMA
Date: 22 Aug 1999 21:55:07 GMT
I try to classify device activities according to their requesting
processes and find the processes use a device the most.
Pete Zaitcev ([EMAIL PROTECTED]) wrote:
:
: Correct, but grossly oversimplificated.
: "current" may be anything during an interrupt regardless of DMA.
:
: What are you trying to accomplish?
:
: --Pete
--
Sincerely,
Yung-Hsiang Lu
[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
******************************
