Linux-Development-Sys Digest #996, Volume #6 Tue, 27 Jul 99 09:14:18 EDT
Contents:
Re: problem with linuxthreads (glibc 2.1) and user stacks (Kaz Kylheku)
Re: when will Linux support > 2GB file size??? (Bloody Viking)
Re: kernel compile (Paul Kimoto)
Re: when will Linux support > 2GB file size??? (Byron A Jeff)
diskless linux stations with multiple displays (Christof Neuberger)
Re: diskless linux stations with multiple displays (Carlos Vidal)
Toshiba DVD-RAM and Linux (Christian Mund)
help on gcc (jievis)
drives mount in linux and dos-like OS's (YamYam)
Re: Toshiba DVD-RAM and Linux (Stefaan A Eeckels)
Re: drives mount in linux and dos-like OS's (Alexander Viro)
Re: HELP: how to measure hard disk access performance on Linux? (James Stevenson)
Re: drives mount in linux and dos-like OS's (Artur Swietanowski)
Re: Intercepting network calls ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: problem with linuxthreads (glibc 2.1) and user stacks
Date: Tue, 27 Jul 1999 05:58:53 GMT
On Mon, 26 Jul 1999 20:36:34 -0500, peter hatch <[EMAIL PROTECTED]> wrote:
>I've just found out that if your application supplies itself with some
>stacks (for instance if your app is a virtual machine) and you use
If your app is a virtual machine, what's it doing messing around with
*real* stacks? :) :) :)
>linuxthreads, everything gets messed up if you get a signal while
>executing in our own stack space.
So what exactly are you doing? Changing stack contexts in a similar
way to setjmp()/longjmp() or any number of user-level threading
schemes? Why bother if you have threads already?
I say, stick to one method or another. Or else, observe the
appropriate caveats.
>There is an assumption in thread_self() (not pthread_self()) that
>assumes that a thread can only execute on a) the process's stack b) a
>thread-specific stack. It makes no allowances for threads that might
>execute on *both* the process stack *and* a user managed stack.
You simply have to avoid making any pthread_* calls when the stack has been
modified to point somewhere other than where the threading implemenation
expects it to be. LinuxThreads discover their own identity by using their stack
pointer. That's just how it is.
The technique you are doing is less than well-defined according to
the standards that govern the language and libraries you are using.
>than anything else. If your application doesn't need to spawn threads
>during a particular execution, then why should it? Looks messy having
>every invocation of the vm show up as 2 processes....
And it doesn't look messy when a HLL program messes with stack pointers? ;)
>So, I'm searching for a better hack.
How about this: have your stacks, but make sure they are in the
same sandbox as where the thread's stack is expected to be.
LinuxThreads maps thread stacks at equal intervals in memory. They are 2
megabytes apart. A given thread's stack region could be subdivided further and
the subdivisions used as multiple stacks. I think that if you did this, then
thread_self() will still work, because all it cares about is that your stack
pointer is within that 2 megabyte box associated with that thread. If that
pointer is in that box, then the calculation done by thread_self() will
succeed. Just stay away from the unmapped guard page at the upper end (i.e.
lowest address)!
How much stack space do you need anyway?
------------------------------
From: Bloody Viking <[EMAIL PROTECTED]>
Subject: Re: when will Linux support > 2GB file size???
Crossposted-To: comp.os.linux.advocacy
Date: Tue, 27 Jul 1999 05:49:25 GMT
In comp.os.linux.advocacy Philip Brown <[EMAIL PROTECTED]> wrote:
: Umm.... a low-end alpha was affordable 2 years ago.
Depends on your definition of "affordable", which is of course a function
of your take-home pay. For a professional making $80K/yr, you're right.
For a postal worker, no. Becuse I'm a postal worker, the Y2K-3 DEC Alphas
were not affordable. :( When Intel starts shipping millions of 64-bit
CPUs, then it will meet my income's definition of "affordable".
Not every Linux fan is a computer professional. A few of us use it becuse
the price is right: Affordable like nothing else. :)
--
CAUTION: Email Spam Killer in use. Leave this line in your reply! 152680
First Law of Economics: You can't sell product to people without money.
4333453 bytes of spam mail deleted. http://www.wwa.com/~nospam/
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: kernel compile
Date: 27 Jul 1999 01:52:24 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> I think i got errors when booting the new
> kernel saying "incorrect version or system map"
This is probably the error message issued by klogd, and is not a
serious error. System.map is created during the kernel-compilation
procedure. See the klogd(8) man page to see where it looks for the
file.
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Byron A Jeff)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 25 Jul 1999 09:37:19 -0400
In article <7ne25i$jcd$[EMAIL PROTECTED]>,
Graffiti <[EMAIL PROTECTED]> wrote:
-In article <[EMAIL PROTECTED]>,
-Philip Brown <[EMAIL PROTECTED]> wrote:
-[snip]
->well, in theory, it is perfectly feasible to implement a filesystem
->WITHOUT using memory mapping. It's just not as fast.
->
->So, the possibilities I see are:
->
->a) maybe the NTFS support doesn't use memory mapping ?
-
-Nononononono, the FILESYSTEM doesn't do memory mapping. The PROGRAMS
-your run do. For example, you can mmap() a file, then use a pointer
-to run around the file and access it instead of using fseek()/ftell()
-and other such. This will break on 32-bit platforms that want to
-access files that need more than 32-bits to represent.
-
-Another thing mmap() is used for is shared libraries. You just get
-a pointer to the location in memory where a shared library's routine
-is instead of using lseek()/read() to grub around in the file.
-All of a sudden, you can't do this anymore.
That's the case if you change the API and force all new programs to use it.
I think most folks are arguing against that.
-
-While people can argue that adding a 64-bit API that has to be
-called directly will alleviate this problem, unless you're willing
-to re-write *ALL* programs, libraries, etc. to explicitly use this
-new API (and incurr a rather nasty performance hit for the "common"
-case of files that will fit in a 32-bit representation of size),
-you can use the new API only in extremely limited circumstances.
-have to religiously find ways to keep the 32-bit and 64-bit areas
-from interacting, and find a way to "synchronize" them, whatever
-that may entail (i.e. keep your buffer cache coherent, etc.).
-
-Of course, this means you break binary compatability all over the
-place and have to emulate things like mmap() with code that will
-slow it down by quite a bit (speed is one reason mmap() is used over
-lseek()/read()).
OK I'm with you up to this point.
A question. Does any of this change if you prohibit mmapping a file over
the size limit? Then adding (or actually using the existing) routines that
have 64 bit file pointers? I just took a peek at the llseek() man page
and it indicated that it doesn't work for files over 2GB. Which seems to
defeat the purpose.
-
->b) make an inhouse tweaked ext2 driver that uses simple buffer-to-buffer
-> coping instead of memory mapping.
-
-Ext2 can handle 64-bit files. ext2fs does not have to be changed. Even
-on 32-bit platforms. Changing ext2fs will not give you 64-bit files on
-32-bit systems. ext2fs on 32-bit platforms is the same as ext2fs on
-64-bit systems.
OK we're finally clear on that. What I'm not clear on is what must be changed
to read/write/llseek 64 bit files in ext2 without mmap. Leave mmap a 32 bit
interface, having it fail on files that are larger that 2G. Then what changes
must be made to access 64 bit files. Or can they not be separated?
I was concerned about file systems stability. You've taken that off the table.
I think having a separate 64 bit seek()/tell() api along with regular read()/
write() semantics would be sufficient to support 64 bit files. mmap() should
be a convenience that could be sacrificed in order to get 64 bit support.
Now how does this impact the VFS which seems to be the missing element in all
of this?
BAJ
------------------------------
From: Christof Neuberger <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: diskless linux stations with multiple displays
Date: Tue, 27 Jul 1999 09:38:48 +0200
Hello dear friends,
I'm looking for a solution or a proven concept with linux stations
driving multiple graphic cards. If possible, the stations should run
diskless.
Thanks in advance,
Christof Neuberger
fon: +49-(0)30-2801-1858
fax: +49-(0)30-2801-1020
email: [EMAIL PROTECTED]
------------------------------
From: Carlos Vidal <[EMAIL PROTECTED]>
Subject: Re: diskless linux stations with multiple displays
Date: Tue, 27 Jul 1999 09:53:05 +0200
Christof Neuberger wrote:
>
> Hello dear friends,
> I'm looking for a solution or a proven concept with linux stations
> driving multiple graphic cards. If possible, the stations should run
> diskless.
Take a look at 'www.igel.de'. If there is something like this they can
provide it.
--
Carlos Vidal
[EMAIL PROTECTED]
------------------------------
From: Christian Mund <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Toshiba DVD-RAM and Linux
Date: 27 Jul 1999 08:31:16 GMT
Hello,
I am the proud owner of a TOSHIBA SD-W1101 DVD-RAM Drive and want to know,
if there is anyone out there, who is able to use this Drive with Linux.
The Drive works in a 2-LUN Mode, LUN0 = CDROM and LUN1 = Optical Device.
Reading from a DVD-Media works fine, but when i try to write, the
Drive hangs up the SCSI-Bus.
I tried to track this problem a little bit, but i am not so familiar with
debugging Kernels .
dmesg says : "aborting command due to timeout : write(6)
timed out: reset"
Using the strace-command i can see, that thwe Device-Hang occurs, when the
Kernel does an fsync.
On the Web, there are patches for other DVD-RAM Drives ( HITACHI GF-1050,
PANASONIC LD-1001 ). These Drives had all the same problem :
They work in a 1LUN Mode and the Kernel detects them as CD-ROMs and not as
Devices with wite-access.The only change in the Kernel is, that these
patches declare these devices as opticals or direct access devices (like
Disks), nothing else.The patches work great with Linux.
I got the Inquiry-Pages from these Drives and found out, that the TOSHIBA
has write-cache and the PANASONIC,HITACHI don�t.
Could it be, that there is a problem with the way, Linux cache pages are
organized compared to the cache on Devices ?
Has anyone solved this ?
Is there any possibilty to track down the SCSI-Commands send out by the
Kernel ?
Any hints welcome and .. Sorry for my poor english.
With kind regards,
Christian Mund
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: jievis <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: help on gcc
Date: 27 Jul 1999 10:31:18 GMT
Hi, All:
When I try to compile a c files, I want gcc output a middle files in
which the expression is computed and enumeration is also computed, the
output files should be also .c format. So who can tell me the switcher?
Thanx in advance
Jievis
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: YamYam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: drives mount in linux and dos-like OS's
Date: 27 Jul 1999 10:31:17 GMT
Hi...
I want to ask about the difference in mount/umount the drivers in
linux 'is it necessary, if so why?' and the easy one in Dos-like
OS's 'e.g., Win95, Win98, ...'.
I found it very complicated for the Dos-like users to switch to linux at
this point. Is there any suggessions to make easy for that user, such as
writing a script to mount/umount the floppy and cdrom?
- markhi1.
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: comp.os.linux.hardware
Subject: Re: Toshiba DVD-RAM and Linux
Date: 27 Jul 1999 09:54:32 GMT
In article <7njqok$ie4$[EMAIL PROTECTED]>,
Christian Mund <[EMAIL PROTECTED]> writes:
> I am the proud owner of a TOSHIBA SD-W1101 DVD-RAM Drive and want to know,
> if there is anyone out there, who is able to use this Drive with Linux.
>
> The Drive works in a 2-LUN Mode, LUN0 = CDROM and LUN1 = Optical Device.
> Reading from a DVD-Media works fine, but when i try to write, the
> Drive hangs up the SCSI-Bus.
I have the Panasonic PD drive (a CD-ROM/650Mb optical combo), that also
uses a 2-LUN approach. With the 2.0.36 kernel, this device works
flawlessly.
> I tried to track this problem a little bit, but i am not so familiar with
> debugging Kernels .
> dmesg says : "aborting command due to timeout : write(6)
> timed out: reset"
> Using the strace-command i can see, that thwe Device-Hang occurs, when the
> Kernel does an fsync.
This looks suspiciously like hardware problems.
<SNIP>
> I got the Inquiry-Pages from these Drives and found out, that the TOSHIBA
> has write-cache and the PANASONIC,HITACHI don�t.
>
> Could it be, that there is a problem with the way, Linux cache pages are
> organized compared to the cache on Devices ?
I don't think so.
> Has anyone solved this ?
> Is there any possibilty to track down the SCSI-Commands send out by the
> Kernel ?
You should compile the kernel with SCSI-debugging enabled.
The commands that are issued are written to syslog (usually
the messages file).
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: drives mount in linux and dos-like OS's
Date: 27 Jul 1999 07:18:20 -0400
In article <7nk1pl$n0i$[EMAIL PROTECTED]>,
YamYam <[EMAIL PROTECTED]> wrote:
>Hi...
>I want to ask about the difference in mount/umount the drivers in
What difference? It's a normal UNIX.
>linux 'is it necessary, if so why?' and the easy one in Dos-like
>OS's 'e.g., Win95, Win98, ...'.
Ah, with those... You mean that gross with 'disk names' instead of unified
tree?
>I found it very complicated for the Dos-like users to switch to linux at
>this point. Is there any suggessions to make easy for that user, such as
>writing a script to mount/umount the floppy and cdrom?
D'oh. So write it... It's a one-liner - mount name_of_the_mountpoint and
there you go. Just add the appropriate line into /etc/fstab (don't
forget to add noauto,user to options field). What's the problem?
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (James Stevenson)
Subject: Re: HELP: how to measure hard disk access performance on Linux?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 27 Jul 1999 11:15:16 +0100
Hi
try droping down into single user mode
then you should get a better answer
X uses a lot of ram
On 26 Jul 1999 19:11:02 -0700, Errin Watusikac <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (John McKown) writes:
>
>> hdparm -t -T /dev/hda
>
>WARNING: I found I got a very different result doing this
>from an X term and from a VT with the X server not running.
--
=============================================
Check Out: http://www.users.zetnet.co.uk/james/
E-Mail: [EMAIL PROTECTED]
11:10am up 36 days, 12:13, 2 users, load average: 0.56, 0.50, 0.30
------------------------------
From: Artur Swietanowski <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: drives mount in linux and dos-like OS's
Date: Tue, 27 Jul 1999 13:18:06 +0200
YamYam wrote:
>
> Hi...
> I want to ask about the difference in mount/umount the drivers in
> linux 'is it necessary, if so why?' and the easy one in Dos-like
> OS's 'e.g., Win95, Win98, ...'.
> I found it very complicated for the Dos-like users to switch to linux at
> this point. Is there any suggessions to make easy for that user, such as
> writing a script to mount/umount the floppy and cdrom?
Read up about automount. RH package name is "autofs". It requires
kernel support, which I think is on by default in RH distributions.
Also, KDE (K Desktop Env.) does mount / unmount via icons, and
the user only needs to do half of the work (i.e., the unmount).
HTH,
=====================================================================
Artur Swietanowski mailto:[EMAIL PROTECTED]
Institut f�r Statistik, Operations Research und Computerverfahren,
Universit�t Wien, Universit�tsstr. 5, A-1010 Wien, Austria
tel. +43 (1) 427 738 620 fax +43 (1) 427 738 629
=====================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Intercepting network calls
Date: 27 Jul 1999 12:49:51 GMT
Anand Paka <[EMAIL PROTECTED]> wrote:
: Hi,
: I'm new to Linux and am looking around for a mechanism to intercept all
: the sockets calls made. My intention is to monitor the socket traffic,
: their types, usage etc. for all application using the network resources.
: (This should be transparent to the application). I want to be able to say
: which application is using which sockets at a given time, together with
: information like how much data has passed in/out on that socket, the
: state of the socket (listening, connected..) etc.
: If any of you have done this or can point me to the resources or have
: any suggestions, please let me know.
This is easily done by using a thin
shim library loaded before the main
program using LD_PRELOAD. The library
defines all the usual socket symbols
(socket, bind, listen, etc.) and emulates
them with calls to underlying symbols
in the glibc library (called __socket,
__bind, etc.), doing whatever processing
is required in between.
I suspect that what you really want is
a good quality network monitoring tool
however, such as netstat.
Rich.
--
[EMAIL PROTECTED] | Free email for life at: http://www.postmaster.co.uk/
BiblioTech Ltd, Unit 2 Piper Centre, 50 Carnwath Road, London, SW6 3EG.
+44 171 384 6917 | Click here to play XRacer: http://xracer.annexia.org/
--- Original message content Copyright � 1999 Richard Jones ---
------------------------------
** 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
******************************
