Linux-Development-Sys Digest #86, Volume #7 Sun, 22 Aug 99 15:14:19 EDT
Contents:
Re: Linux - Memory model / protection scheme (Ulrich Weigand)
Re: real-time kernel module ("Norm Dresner")
PCI Programming (Mad Matt)
vram needed?? ("young")
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Jonas Utterstrom)
Re: Linux's faults (Robert Krawitz)
Re: PCI Programming (Philip Armstrong)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and (Brian Poe)
Re: My first linux program: non-bios boot loader (H. Peter Anvin)
Re: update_vm_cache (Greg Lee)
General purpose serial PCI driver available for testing (Otto Moerbeek)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Ulrich Weigand)
IPSec for Linux (Michael Thomas)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Philip Armstrong)
Autoscan, Autoconf, and Automake - HOWTO? (Stephen Torri)
Re: Linux - Memory model / protection scheme (Todd Knarr)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Josh Stern)
Re: why not C++? (Randall Parker)
Re: threads (Randall Parker)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Ulrich Weigand)
Subject: Re: Linux - Memory model / protection scheme
Date: 22 Aug 1999 16:54:02 +0200
"Pizzi" <[EMAIL PROTECTED]> writes:
>The rest of your message was all new to me, thanks. I knew windows' security
>was weak, but i didn't know it was THAT weak. heheh. i'll put all that down
>on my list of cool ways to crash windows. where do you learn stuff like
>that? i've been programming windows '95 in assembly to try to learn the
>internals, yet as i said, all that you just wrote was foreign to me.
Well, e.g. Matt Pietrek's books contain a lot of information of this sort
('Windows Internals', 'Windows 95 System Programming Secrets').
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Re: real-time kernel module
Date: 22 Aug 1999 15:02:05 GMT
Have you looked at Real-Time Linux? (IIRC, www.rtlinux.org)
Norm
Netnoice <[EMAIL PROTECTED] > wrote in article
<[EMAIL PROTECTED]>...
> 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
>
------------------------------
From: Mad Matt <[EMAIL PROTECTED]>
Subject: PCI Programming
Date: Sun, 22 Aug 1999 15:33:04 GMT
Hiya,
Is it all possible to do any programming regards the PCI bus? I've seen
the <linux/pci.h> file which contains everything I need, but knocking up
a small program just lists errors about not finding these functions, and
I haven't a clue which libs, if any, contain them.
The only reason I ask, is that I have finally found how to get my
blasted soundcard working under linux, (an ESS 1978). All I need to do
is change one bit in the PCI configuration space to enable the SB legacy
support.
Can anyone offer any advice? If I can't do it this way, are there any
alternatives?
Thanks in advance
Matt
------------------------------
From: "young" <[EMAIL PROTECTED]>
Subject: vram needed??
Date: 22 Aug 1999 15:38:42 GMT
Hello..
I'm porting.. linux arm test board..
but I has problem vram, test board not has vram.
I'm compiling kernel (cross compile arm core.)
and copying the kernel in test board.
and booting system, and I got the problem "VRAM error".
what is solution this problem? Must has VRAM ?
this solution is only? vram is necessary on boot linux?
please send mail at " [EMAIL PROTECTED] "
or post this news group.
I'm poor english ability. sorry..
Good day..
Open, Funny, Free..
------------------------------
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 16:32:47 GMT
In article <7pomi8$9fv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Philip Armstrong) wrote:
> 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?
>
[ ... ]
>
> 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?
Partly, but you may want export/import anyway of bloating reasons. I
explain this in a non-technical way, since I don't know the inner
workings of dlls and shared ELF libraries.
One of purposes of exporting functions in dll:s is to avoid exporting
internal datastructures that shouldn't be visible outside the shared
library. Of course one easy way of hiding the internal data is to
avoiding install the internal *.h files. And this also makes it
necessary to avoid includes to the internal h-files from the public
h-files.
But in C++ this is not enough, since C++ classes makes the shared
libraries substantially larger. An easy example of that is to first
compile a static C++ library and then compile it as a shared library.
Notice that the shared library is much larger.
This means that much of the library is bloated with export information.
In large applications such as Mozilla this is not acceptable. Imagine
the Linux heads wonder why Mozilla/Linux is twice as big as
Mozilla/Windows. Therefore, specifying what classes that you want to
have exported is important.
On the other hand, C would also benefit from this. One problem with
glibc is that developers have relied on internal functions, which have
been removed in newer versions(glibc-2.0 -> glibc-2.1). Those problems
would have been non-existant if exporting similar to Windows had been
used.
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.
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.
/Jonas U
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Subject: Re: Linux's faults
Date: 22 Aug 1999 12:51:49 -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.
What kernel and libc are you using? Newer kernels and/or glibc 2.1
might improve things in this regard.
> 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.
So you want a single process that's going to provide service to 500
users, and each user will consume more than 2 file descriptors? You
might want to take another look at the architecture of your server.
Is it really necessary for all running instances of the server to live
within the same address space, or are you merely trying to optimize
away something (context switch overhead) that isn't too much of a
problem under Linux? Or do your server instances share some data, but
don't really need to live within the same process? I believe that NT
doesn't have a fork() system call to simply clone a process, so that
eliminates the kind of design I'll outline below for that purpose, but
you should consider it under Linux.
Traditional Unix servers are handled by a master server forking a
child to handle each request. The master merely listens for requests,
forks them off, and reaps the dead children (with periodic waitpid()
calls). This is so common, in fact, that there is a "master" daemon
called inetd that performs this service for many servers, as described
in /etc/inetd.conf. This takes care of all of these details. Since
many servers have additional security requirements that inetd can't
handle directly, there's an additional program (in Linux) called tcpd
that does security checks before finally invoking the real service
process.
This works well for typical servers that establish long-lived
connections, such as rlogin, telnet, ftp, and so forth. It could be
done for email too, but email is high volume and typically the mailer
wants to be able to reject connections when the load gets high without
the expense of forking and exec'ing additional processes. So sendmail
(the most common Unix mail daemon) runs as a standalone daemon, but it
operates the same way -- a master listens for requests and forks off a
worker process to handle each connection.
If you need to share memory between the workers, all is not lost
either. It's possible for processes to share memory by means of the
System V shared memory primitives (shmctl and such), or by mmap()'ing
a file shared (the traditional method).
Linux also has a system call named clone() that allows two processes
to share a number of resources. Don't use this, though, if you want
your program to be portable.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Subject: Re: PCI Programming
Date: 22 Aug 1999 15:54:16 GMT
In article <Pine.SOL.3.95.990822162705.23048A-100000@harrier>,
Mad Matt <[EMAIL PROTECTED]> wrote:
>The only reason I ask, is that I have finally found how to get my
>blasted soundcard working under linux, (an ESS 1978). All I need to do
>is change one bit in the PCI configuration space to enable the SB legacy
>support.
>
>Can anyone offer any advice? If I can't do it this way, are there any
>alternatives?
setpci / lspci may do what you need
part of the pciutils package under debian.
Phil
--
nosig
------------------------------
From: Brian Poe <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
Date: Sun, 22 Aug 1999 16:34:46 GMT
To clarify;
Under VC++ in Win32, the lack of __declspec(dllexport) indeed does
remove the function symbol from the dll.
-Brian
>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)
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: My first linux program: non-bios boot loader
Date: 8 Aug 1999 22:01:55 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: Peter Mutsaers <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> >> "HPA" == H Peter Anvin <[EMAIL PROTECTED]> writes:
>
> >> I think so, but then I don't know why NT can't handle lilo
> >> being in the MBR. I would assume that nuni would work in /hda1
> >> (for example) the same as lilo for NT users.
> >>
>
> HPA> Because NT stores nonstandard data in the MBR (quite possibly
> HPA> to intentionally screw up other OSes).
>
> Hmm, not knowing this, I installed Linux at work (RH6.0) with lilo
> using the MBR. I can still boot NT. How can this be, did RH modify
> lilo to make this possible?
>
No, Werner did, AFAIK.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
From: Greg Lee <[EMAIL PROTECTED]>
Subject: Re: update_vm_cache
Date: 22 Aug 1999 16:46:33 GMT
newsseeker <[EMAIL PROTECTED]> wrote:
...
: The VFAT support in 2.3.12 is broken, therefore, do not include VFAT file
It's fixed in 2.3.14 -- I just tried it. However, ppp (v. 2.3.5) no longer
works in 2.3.14.
...
--
Greg Lee <[EMAIL PROTECTED]>
------------------------------
From: Otto Moerbeek <[EMAIL PROTECTED]>
Subject: General purpose serial PCI driver available for testing
Date: Sun, 22 Aug 1999 19:43:53 +0200
Reply-To: [EMAIL PROTECTED]
Hi to you all,
I have a patch for the serial driver available for testing on my
homepage. The patch should provide support for any "dumb" serial PCI
card with very little effort (just filling in some entries in a table).
Take a look at <http://people.a2000.nl/omoerbe/> for more information
and the patch. Any feedback is very welcome!
Regards,
Otto
--
Otto Moerbeek
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Ulrich Weigand)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
Date: 22 Aug 1999 19:32:41 +0200
[EMAIL PROTECTED] (Kaz Kylheku) writes:
>Because libraries sometimes grow sophisticated enoguh that they have to be
>broken into multiple translation units. Yet these modules have to communicate
>with each other. These communication pathways are intended to be private to the
>library, yet they are visible due to the unavoidable of identifiers with
>external linkage.
>These ``private externals'' pollute the namespace of the library user.
>What's worse, the library user can override these symbols!
Provided you use binutils version 2.9.1 or later, there is a way around
this: you can 'localize' symbols using the objcopy -L flag, which means
the symbol is treated from now on as if it were local (had been declared
'static' in C).
So, you link all your library objects together into one big .o file
(using ld -r or so), apply objcopy -L to localize all symbols you
don't want to export, and then create the shared object from the
resulting .o file ...
While this is somewhat convoluted, it should work :-/
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
------------------------------
From: Michael Thomas <[EMAIL PROTECTED]>
Subject: IPSec for Linux
Date: 22 Aug 1999 10:54:16 -0700
I browsed through the 2.2 sources and it doesn't
seem that there is any IPSec stuff in either ipv4
or ipv6. Did I miss something? Is there any work
going on to bring IPSec into the fold?
--
Michael Thomas ([EMAIL PROTECTED] http://www.mtcc.com/~mike/)
"I dunno, that's an awful lot of money."
Beavis
------------------------------
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 17:27:00 GMT
In article <7pp8nf$fuo$[EMAIL PROTECTED]>,
Jonas Utterstrom <[EMAIL PROTECTED]> wrote:
>In article <7pomi8$9fv$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Philip Armstrong) wrote:
>> Does this make sense?
>
>Partly, but you may want export/import anyway of bloating reasons. I
>explain this in a non-technical way, since I don't know the inner
>workings of dlls and shared ELF libraries.
true, I had forgotten this issue.
>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 :)
>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...
Phil
--
nosig
------------------------------
From: Stephen Torri <[EMAIL PROTECTED]>
Subject: Autoscan, Autoconf, and Automake - HOWTO?
Date: Sun, 22 Aug 1999 13:30:06 -0400
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?
Stephen
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Subject: Re: Linux - Memory model / protection scheme
Date: 22 Aug 1999 18:07:20 GMT
Ulrich Weigand <[EMAIL PROTECTED]> wrote:
> 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
True, but since it's a constant it doesn't really affect the amount of
space needed for page tables so I'm ignoring it for purposes of a basic
discussion. Ditto for the tricks you can play with it to create holes in
the virtual address space ( within limits ).
> 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!
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. Still, you don't need to have
page table entries for the entire 4GB virtual address space as the
original poster thought.
--
It may be great to soar with the eagles, but weasels don't get sucked into
jets.
------------------------------
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 17:31:49 GMT
Jonas Utterstrom <[EMAIL PROTECTED]> wrote:
>One of purposes of exporting functions in dll:s is to avoid exporting
>internal datastructures that shouldn't be visible outside the shared
>library. Of course one easy way of hiding the internal data is to
>avoiding install the internal *.h files. And this also makes it
>necessary to avoid includes to the internal h-files from the public
>h-files.
>
>But in C++ this is not enough, since C++ classes makes the shared
>libraries substantially larger. An easy example of that is to first
>compile a static C++ library and then compile it as a shared library.
>Notice that the shared library is much larger.
>
>This means that much of the library is bloated with export information.
>In large applications such as Mozilla this is not acceptable. Imagine
>the Linux heads wonder why Mozilla/Linux is twice as big as
>Mozilla/Windows. Therefore, specifying what classes that you want to
>have exported is important.
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
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.
- Josh
------------------------------
From: [EMAIL PROTECTED] (Randall Parker)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Sun, 22 Aug 1999 11:14:53 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> I've also found it more difficult to debug C++ than C (especially the
> code of other people,) because (operator) overloading can make otherwise
> innocent looking code do much more than you had expected.
I have worked on C++ dev projects where everyone agreed not to do
operator overloading precisely so that the code would stay
comprehensible.
I think the desire to make string classes and then be able to concatenate
strings together with + is the reason most found the idea appealing.
However, I think operator overloading is a bad idea for the most part.
In the words of an old programmer who told me this while I was a
much younger one:
"Code is written once to be read many times"
------------------------------
From: [EMAIL PROTECTED] (Randall Parker)
Subject: Re: threads
Date: Sun, 22 Aug 1999 11:36:51 -0700
In article <jonu3.10936$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Based on the experiences that I've seen thus far with threads, they
> add complexity, tighten interfaces that often should be loosened, and
> appear valuable as a tuning tool rather than as a
> "tool-for-all-occasions."
Criticizing threads for this is equivalent to critcizing C for allowing
people to use pointers in ways that scribble over memory and cause
crashes.
When you use threads they can have their interfaces to each other done in
ways that are wrong wrong wrong. Is this an argument against threads per
se? No, I think it is an argument against bad programming practices. The
use of threading just introduces more constraints and more need for skill
and discipline when writing code.
If someone uses threads and that person doesn't know what a critical code
section is or doesn't know how to do mutexes to serialize access to data
areas that multiple threads share then trouble can and will result.
Lots of Unix programmers (and not a few Win3.1 programmers for that
matter) have spent years not worrying about what they do in their own
thread of execution as it relates to other threads running in other
processes. They all have their own sandbox to play in. Well, along comes
threads and just like with pointers its like they have had their training
wheels taken away for the first time. Crashes and very botched
programming jobs will result.
Interfaces ought to be well defined. When memory is shared there is a
temptation to just go hog wild with different threads accessing and
updating different fields in shared structures (what, you can't have 2
threads inserting items into a linked list at the same time?) and so on.
Another classic is passing a pointer to a stack variable of one thread to
another thread.
But threads are incredibly useful if your programming team has both the
knowledge and the discipline to use them wisely. Lots of existing
programs that enforce a very serial approach to doing various operations
could benefit enormously from threading.
I find the whining of Unix programmers about threads to be kinda like
baby duck syndrome. What, I have to learn something about an API that
didn't first show up on Unix and that Unixes competitors have been
touting as an advantage for years? Well, given that Unix isn't going to
be getting VMS's queued IO model then kernel level threading is, IMO, the
next best thing.
Aside: IME the programs that were written for OS/2 were some of the most
well threaded that I've encountered. Threading was trumpeted as one of
the big OS/2 advantages over Win3.0 way back when. Some people did very
good jobs with implementing threaded programs on OS/2. There are
literally orders of magnitude more Win32 programs than OS/2 programs and
Win32 also has threading calls the Win32 programs on average are less
well threaded than OS/2 programs that I've used.
------------------------------
** 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
******************************
