Linux-Development-Sys Digest #85, Volume #7 Sun, 22 Aug 99 11:13:54 EDT
Contents:
efficieny ([EMAIL PROTECTED])
Re: Linux's faults (Mark Hamstra)
Re: Linux's faults (Mark Hamstra)
Re: threads (NICHOLAS DRONEN)
Re: Linux - Memory model / protection scheme (Todd Knarr)
Can GLIBC-2.1.1 Be Compiled Using GCC-2.95? (Habibi4me)
Re: Can GLIBC-2.1.1 Be Compiled Using GCC-2.95? (Andreas Jaeger)
Re: 497.2 days ought to be enough for everybody ([EMAIL PROTECTED])
Re: X Windows developement (Don Waugaman)
Re: glibc-2.1.1 problems (Andreas Jaeger)
Attention all C/C++ Programmers ("+++Durandal+++")
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Philip Armstrong)
Re: Linux's faults (XuYifeng)
Re: Linux - Memory model / protection scheme ("Ron Ruble")
real-time kernel module (Netnoice)
Re: 3com ISA cards and linux (See sig for reply)
Re: Linux - Memory model / protection scheme (Ulrich Weigand)
Re: glibc-2.1.1 problems (Allin Cottrell)
Re: PROPOSAL: A secure, simple NIS replacement ("Norm Dresner")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: efficieny
Date: Sun, 22 Aug 1999 07:20:50 GMT
Hi, I wasn't sure the best place to post this message, so I'm hoping
this NG is good. I'm trying to figure out the most efficient method of
passing data between two seperate threads using a pointer to the same
data structure.
The problem is of course that because both threads are using the same
data, they can change it at the same time. The most obvious method that
I can think of is to use a mutex (or metaphors, etc) to protect the
data, and do a loop waiting for the data to become free once its passed
via a function call. The problem I see with this the wait, which may not
be neccessary in this case.
One thread is simply passing data (more specifically XEvents) to the
other thread. Therefore the other possibility is to allocate memory for
each event being sent over, in which case the two threads are not
working on the same data, and do not need to be synchronized. I am
afraid, however, that the cost of memory allocation could be huge,
especially since each time the mouse moves an event is sent.
I could always do a hybrid of both, and create a large array of
preallocated events (I'm actually wrapping XEvents in a C++ wrapper),
and have an index to keep track of which on is in use. After each
variable is sent, a lock is placed on each variable, until it gets
released. It would of course be assuming that each event is processed
serially (which it is).
Any insight would be greatly appreciated. I don't have much experiance
programming Linux threads (or just threads for that matter), so I'm not
quite sure what to expect.
Thank you,
Abe
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Mark Hamstra <[EMAIL PROTECTED]>
Subject: Re: Linux's faults
Date: 22 Aug 1999 03:33:35 -0400
Mark Hamstra <[EMAIL PROTECTED]> writes:
> So redefine the max open file descriptor constant and rebuild your
> kernel -- problem's gone.
Actually, come to think of it, I don't think you even have to do
that much anymore. I believe you can just write a new value to
file-max in /proc and change the max number of file descriptors on
the fly.
--
Mark Hamstra
Bentley Systems, Inc.
------------------------------
From: Mark Hamstra <[EMAIL PROTECTED]>
Subject: Re: Linux's faults
Date: 22 Aug 1999 03:30:07 -0400
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.
>
> unlike WindowsNT, it fd_set structure is not constructed in bitmap
> structure
> (Linux is in this way), also NT's default fd_set size is 64, but it can
> put any socket
> handle into this structure and call select()!
> I recently encounter the problem, I am designing a server application,
> on NT I
> can give service to 500 users without any problem, but on Linux using
> pthread library,
> it prevent me from open files and socket handles more than 1024.
>
> by the way, Linux has too many limits.
So redefine the max open file descriptor constant and rebuild your
kernel -- problem's gone.
--
Mark Hamstra
Bentley Systems, Inc.
------------------------------
From: [EMAIL PROTECTED] (NICHOLAS DRONEN)
Subject: Re: threads
Date: Sun, 22 Aug 1999 08:44:47 GMT
[EMAIL PROTECTED] wrote:
: On Wed, 18 Aug 1999 12:33:24 +1000, M van Oosterhout
: <[EMAIL PROTECTED]> wrote:
: >Processes on Linux are *very* cheap. A process context switch on Linux
: >takes less time than a thread context switch on NT.
: Can you provide any proof?
Someone posted the same claim to the 'Why fork?' thread on
comp.unix.programmer a few months ago. I think he'd lost
his original data to back that up, but he did post a followup
or two on it.
Nicholas
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Subject: Re: Linux - Memory model / protection scheme
Date: 22 Aug 1999 08:58:41 GMT
Pizzi <[EMAIL PROTECTED]> wrote:
> i see... but don't the page tables still have to be there though? even if
> only entries for the 4mb's are filled out?
The page tables have to be there, yes. However, they only have to be big
enough to hold the entries for the pages that actually exist ( assuming
the mapped space is contiguous, IIRC page table entries need to cover
contiguous regions ( but then it's easy to insure that the virtual address
space in use doesn't have holes in it ) ). Thus, if a process has 4MB
of memory space, it needs a page table 1024 entries long.
--
It may be great to soar with the eagles, but weasels don't get sucked into
jets.
------------------------------
From: Habibi4me <[EMAIL PROTECTED]>
Subject: Can GLIBC-2.1.1 Be Compiled Using GCC-2.95?
Date: Sat, 21 Aug 1999 11:46:21 -0400
Has anyone had a successful story compiling glibc-2.1.1 using gcc-2.95?
I have just compiled and installed a full version of gcc-2.95 on my
SuSE-6.1 Linux distro. When I tried to compile the glibc-2.1.1 using
gcc-2.95, it failed with a bad message on gcc-2.95 while configuring the
glibc-2.1.1:
loading cache ./config.cache
checking host system type... i586-pc-linux-gnu
checking sysdep dirs... sysdeps/i386/elf crypt/sysdeps/unix
linuxthreads/sysdepschecking
for a BSD compatible install...
/usr/bin/ginstall -c
checking whether ln -s works... yes
checking build system type... i586-pc-linux-gnu
checking for gcc... gcc
checking version of gcc... 2.95, bad <====== ************
checking for make... make
checking version of make... 3.76.1, ok
checking for msgfmt... msgfmt
checking version of msgfmt... 0.10.35, ok
checking for makeinfo... makeinfo
checking version of makeinfo... 1.68, ok
configure: error:
*** Some critical program is missing or too old.
*** Check the INSTALL file for required versions.
The INSTALL file from the glibc did not mention that gcc-2.95 cannot be
used to compile the glibc-2.1.1. Any suggestion or input?
--
[EMAIL PROTECTED]
PS. Remove "4m" from e-mail address to enable reply.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: Can GLIBC-2.1.1 Be Compiled Using GCC-2.95?
Date: 22 Aug 1999 09:46:21 +0200
>>>>> Allin Cottrell writes:
Allin> Habibi4me wrote:
>>
>> checking build system type... i586-pc-linux-gnu
>> checking for gcc... gcc
>> checking version of gcc... 2.95, bad <====== ************
Allin> To get the configure process to work for glibc 2.1.1 with
Allin> gcc 2.95, do:
Allin> Open the file "configure" in an editor and search for the first
Allin> line containing "egcs". It should start like this
Allin> egcs-2.9[1-9].*|egcs-2.90.2[789]...
Allin> stick the string "2.95|" in front of the existing line, save the
Allin> file, then configure as usual. Gcc 2.95 postdates glibc 2.1.1,
Allin> and "configure" fails because it's not expecting the string that
Allin> 2.95 produces when fed "gcc -v".
Your explanation is right. Nevertheless I do advise against this.
gcc 2.95 comes with new alias analysis rules. If you use glibc 2.1.1
together with gcc 2.95, you should use -fno-strict-aliasing to compile
glibc and all programs that use glibc since some files violate the
strict aliasing rules:-(.
This will be fixed in glibc 2.1.2.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 497.2 days ought to be enough for everybody
Date: Sun, 22 Aug 1999 09:23:58 GMT
What is this jiffies thing anyway? Why do you have an internal clock
when you can use the rtc? I have seen jiffies in kernel code being
used for some kind of timeouts or interrupts, what is it used for?
- David Belius
>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 :)
>
>Thanx & (:ul8er, r@y
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Subject: Re: X Windows developement
Date: 21 Aug 1999 08:41:12 -0700
In article <Gmpv3.16215$[EMAIL PROTECTED]>,
Christopher Browne <[EMAIL PROTECTED]> wrote:
>
>An creative alternative might be to see if you could get some funding
>from The Project to buy a documentation set. That would appear to lie
>within the parameters of what their policies allow them to fund, and
>should represent a reasonably valuable way to use funds.
I'd think that the XFree86 Project should have some amount of pull with
the publishers of good X documentation sets to be able to get a break
on prices, considering that the better XFree86 gets, the broader and
more lucrative the X market will become.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
We are not altering the real to suit the ideal. We are altering the ideal:
it is easier. - G. K. Chesterton
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: glibc-2.1.1 problems
Date: 22 Aug 1999 09:47:59 +0200
>>>>> Mike Dowling writes:
> I have two computers. Strangely, when I upgraded to glibc-2.1.1 on one of
> them (a pentuim II), I experienced only teething problems. On the other, a
> Pentium, I'm having major problems.
> The problem is that virtually every binary now cannot be executed as the
> shared libraries don't appear to have certain functions. This did also
> happen on the first computer, but only a handful of binaries were affected,
> and these have since been all re-compiled.
What kind of problems do you have exactly? Please read the whole FAQ,
it mentions a number of problems and solutions already.
> The only thing left that I can think of is to simply copy the various
> binaries from /bin, /lib/ /usr/bin, /usr/lib, and also /usr/include and
> /usr/info from the one computer to the other. Am I right in assuming that
> binaries for the Pentium II are compatible with the Pentium?
No, you're not right. Read the glibc2 FAQ:
1.18. How can I compile on my fast ix86 machine a working libc for my slow
i386? After installing libc, programs abort with "Illegal
Instruction".
{AJ} glibc and gcc might generate some instructions on your machine that
aren't available on i386. You've got to tell glibc that you're configuring
for i386 with adding i386 as your machine, for example:
../configure --prefix=/usr i386-pc-linux-gnu
And you need to tell gcc to only generate i386 code, just add `-mcpu=i386'
(just -m386 doesn't work) to your CFLAGS.
{UD} This applies not only to the i386. Compiling on a i686 for any older
model will also fail if the above methods are not used.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: "+++Durandal+++" <[EMAIL PROTECTED]>
Subject: Attention all C/C++ Programmers
Date: Sat, 21 Aug 1999 22:19:45 -0400
We have a spare-time job for all qualifying programmers. Previous
experience in kernel and X development would help. All those that would
like to help should send a resume to [EMAIL PROTECTED] In the
subject, put Resume. There are several jobs available, from application to
kernel development. We even offer a free course to those who would like to
learn C or C++ if they agree to work for us afterwards. We make both
licensed and GPL'd software.
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
Date: 22 Aug 1999 11:22:48 GMT
In article <7plpf8$qsd$[EMAIL PROTECTED]>,
Noam K <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I am trying to write a shared library which exports only some of its
>functions.
>
>In windows this is easily done by creating a DLL and using
>__declspec(import) or (export).
>
>Any ideas how this is done in Linux? are there different solutions for a.out
>and ELF libraries?
you might be able to remove symbols with judicious use of ar, nm and
possibly strip. Putting all your internal functions in a specific ELF
section so you can dump the symbols in one go might be the way to go.
I'm not sure you really want to do this though. It depends how those
functions are being called internally.
I have a question though. Why do you want to do this? The usual
pattern as far sa I can see is to put your public functions in the
header files for the library, and leave the private ones out. If
programmers are dumb enough to call functions in a library which
aren't defined in the headers then they are on their own :)
Looking at a few linux libraries seems to confirm this.
I have a feeling that the code set up by the __declspec function
attributes in the win32 environment is duplicated by the dynamic
linker under linux.
Looking at the documentation, it seems that __declspec(import) and
__declspec(export) are needed to ensure that those functions appear in
the global symbol table under win32. Under linux (and other unices)
the dynamic linker takes care of symbol references, and no explicit
'export' of a library function is necessary for a library to link
properly.
This implies that you're looking at things from the wrong point of
view. __declspec under windows is needed to ensure that functions
appear in the global symbol table. The lack of a 'declspec' may not
remove the function symbol from the dll itself, though it presumably
won't appear in the global symbol table for that process (this is
supposition incidentally---I don't have a windows machine available to
check)
So I think what you are trying to do may be based on a misapprehension
of what __declspec actually does under windows. (sticking my neck out
here :) --- I know *nothing* about win32 linking, and this is
inference from hints in the linux documentation.)
Does this make sense?
Phil Armstrong
--
nosig
------------------------------
From: XuYifeng <[EMAIL PROTECTED]>
Subject: Re: Linux's faults
Date: Sun, 22 Aug 1999 19:57:09 +0800
Hi,
I think you misunderstand something, the fd_set structure uses bitmap
structure,
it can only hold max file handle No. is 1023, even you increase
max_file_open limit,
and can open 1024th file and close all file handle except this 1024th
file handle,
there is still no way to put this 1024th file No. into this structure
and call select()
function, you are rejected out of the door, someone may think I can use
poll() functions,
but remember poll() function is not thread-safe, and Linux Pthread
Library does not
support it!
---
XuYifeng
problem is if I open 1025th socket, then want to put this handle into
fd_set use FD_SET macro,
Mark Hamstra wrote:
> Mark Hamstra <[EMAIL PROTECTED]> writes:
>
> > So redefine the max open file descriptor constant and rebuild your
> > kernel -- problem's gone.
>
> Actually, come to think of it, I don't think you even have to do
> that much anymore. I believe you can just write a new value to
> file-max in /proc and change the max number of file descriptors on
> the fly.
>
> --
> Mark Hamstra
> Bentley Systems, Inc.
------------------------------
From: "Ron Ruble" <[EMAIL PROTECTED]>
Subject: Re: Linux - Memory model / protection scheme
Date: Sun, 22 Aug 1999 08:27:30 -0400
Pizzi wrote in message <7pmm6h$s63$[EMAIL PROTECTED]>...
>How does Linux implement memory protection? All I know is that it is in a
>flat memory model, it uses page-level protection, but somehow uses much
more
>complete protection than Win32 does.
They're actually very similar. One of the reasons NT's
memory protection may seem less complete is that
old problem of backward compatibility.
Jeff Richter's 'Advanced Windows' has an interesting
chapter on the memory layout in NT and 95, showing
all sorts of areas where invalid accesses are handled
in unusual ways because so much old code accesses
the memory. So an invalid memory access to *this
range of memory may be handled by raising an
user-mode exception, while another is handled by
the kernel without raising an exception to the
process.
------------------------------
From: [EMAIL PROTECTED] (Netnoice)
Subject: real-time kernel module
Date: Sun, 22 Aug 1999 13:24:33 GMT
Reply-To: netnoice-NOSPAM-#@freemail.it
I was reading that with linux we can change the standard scheduler;
but I haven't understood if is it possible for a kernel mode module to
became a real time task (I need it to reply quickly to an irq signal)
Thank you
Netnoice
------------------------------
Crossposted-To:
at.linux,aus.computers.linux,be.comp.os.linux,comp.os.linux,comp.os.linux.advocacy,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.networking
From: See sig for reply <[EMAIL PROTECTED]>
Subject: Re: 3com ISA cards and linux
Date: Sat, 21 Aug 1999 13:21:05 GMT
X-No-Archive: yes
On Sat, 21 Aug 1999, Kalkas wrote:
> I have been seriously thinking to use Linux and stop using Windows 98. I am
> fascinated by Linux's stability and security.
I agree.
> However, it seems that it is not possible for me to use Linux, since I use
> cable modem with a 3com ISA card. More precisely, I use 3com EtherLink III
> ISA (3C509/3C509b) network interface card, and there are no drivers which
> will support my card in Linux.
Ooops?
One of my Linux boxes does use a 3C509. Had no problems to get it running.
Even the Linux which included kernel 2.0.33 supported it.
Cheers,
Detlef.
--
Detlef Marxsen at 53 27 N 09 57 E.
Due to bad spam experience, my header is faked. To send email to me
remove the ".no" from [EMAIL PROTECTED]
Sorry for the inconvenience.
May the bugs and computer-viruses eat the spammers alive!
------------------------------
From: [EMAIL PROTECTED] (Ulrich Weigand)
Subject: Re: Linux - Memory model / protection scheme
Date: 22 Aug 1999 16:49:34 +0200
Todd Knarr <[EMAIL PROTECTED]> writes:
>Pizzi <[EMAIL PROTECTED]> wrote:
>> i see... but don't the page tables still have to be there though? even if
>> only entries for the 4mb's are filled out?
>The page tables have to be there, yes. However, they only have to be big
>enough to hold the entries for the pages that actually exist ( assuming
>the mapped space is contiguous, IIRC page table entries need to cover
>contiguous regions ( but then it's easy to insure that the virtual address
>space in use doesn't have holes in it ) ). Thus, if a process has 4MB
>of memory space, it needs a page table 1024 entries long.
Eh, it doesn't work quite this way ;-) On Intel, you have a two-level
virtual address translation mechanism: On top, there is the page directory,
which itself occupies exactly one page of memory (4 KB), and contains
the page numbers of 1024 page tables. Each of the page tables themselves
contain the page numbers of 1024 pages. Thus, a virtual address is split
into three parts: the top 10 bits index the page table inside the page
directory, the next 10 bit bits index the page inside the page table,
and finally the last 12 bits index the address inside the page (on page
is 4 KB in size).
Now, you'll always have to have a page directory. But, you can mark
an entry in the page *directory* as non-present, so that you don't
need a page table for that 4 MB rage. And, of course, you can mark
entries in a page table non-present, so you need to allocate only
those pages that are currently in use. Most certainly the virtual
address space in use *can* have holes in it, though!
So, in total, you need one page directory (1 page) plus one page table
for each 4MB range in use. If your app fits within a 4MB range completely,
you need just one page to hold the page table.
Furthermore, the OS can perform optimizations: e.g. in Windows 95,
not every app has in fact its own page directory. Instead, there is
just one page directory that is always in use. On task switch, the OS
replaces those entries in that shared page directory that point to
private page tables (in the range 4MB - 2GB) with those appropriate for
the new process. All the entries that point to the shared range (0..4MB
and 2GB-4GB) are left untouched, so that these remain valid in all
processes.
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
------------------------------
From: Allin Cottrell <[EMAIL PROTECTED]>
Subject: Re: glibc-2.1.1 problems
Date: Sun, 22 Aug 1999 10:26:07 -0400
Mike Dowling wrote:
> Am I right in assuming that
> binaries for the Pentium II are compatible with the Pentium?
No!! Beware!! C libraries compiled with optimization for i686
may fail horribly on i586 with all sorts of "illegal instruction"
messages. I found this out the hard way.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix
Subject: Re: PROPOSAL: A secure, simple NIS replacement
Date: 22 Aug 1999 15:00:58 GMT
[EMAIL PROTECTED] wrote in article <7pnt0t$kf9$[EMAIL PROTECTED]>...
> I woke up this morning with an idea for an NIS replacement almost fully
> formed in my head. It is so elegant that I had to share in the hopes
> that some folks out there would take on the challenge.
>
[BIG SNIP]
I think that much of what you propose already exists in SAMBA. Granted
that it has problems of its own, but it may still be easier to solve them
than to create a completely new, incompatible protocol. And SAMBA has a
lot more too.
Norm
------------------------------
** 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
******************************
