Linux-Development-Sys Digest #969, Volume #6 Fri, 16 Jul 99 17:14:18 EDT
Contents:
Re: IO Completion Ports (Kaz Kylheku)
IO Completion Ports (Matthew Carl Schumaker)
Re: Bug of GCC (Scott Lanning)
Re: need insight on RH 6.0 executable loading problem (peter hatch)
Re: Makefiles for multiple programmers (Scott Lanning)
RFC 959 linux ftpd, Contivity Extranet Switch (Richard Demanowski)
Re: IO Completion Ports (Matthew Carl Schumaker)
Re: Bug of GCC (Scott Lanning)
Re: DMA from/to user space? (Robert Kaiser)
Re: DMA from/to user space? (Robert Kaiser)
Re: RCS question (bill davidsen)
Re: Bug of GCC (Scott Lanning)
Re: when will Linux support > 2GB file size??? (bill davidsen)
Re: modem still won't work (M. Buchenrieder)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: IO Completion Ports
Date: Fri, 16 Jul 1999 19:14:05 GMT
On Fri, 16 Jul 1999 14:49:56 -0400, Matthew Carl Schumaker <[EMAIL PROTECTED]>
wrote:
>I've been trying to find info about IO completion ports under linux
>but the only info I have dates back to May of 1998
Linux doesn't have IO completion ports. This is a Windows NT (and possibly
VAX?) concept.
>Anybody know if there has been any progress on that front?
In the POSIX world, the rough equivalent is asynchronous I/O, so the question
would be what the status of *that* is.
------------------------------
From: Matthew Carl Schumaker <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: IO Completion Ports
Date: Fri, 16 Jul 1999 14:49:56 -0400
I've been trying to find info about IO completion ports under linux
but the only info I have dates back to May of 1998
Anybody know if there has been any progress on that front?
Pointers to Info?
thanks in advance
matt
Matthew Carl Schumaker
UPAC Lights Administrative Chairperson
[EMAIL PROTECTED]
veni, vedi, velcro
I came, I saw, I stuck around
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 19:35:19 GMT
David T. Blake ([EMAIL PROTECTED]) wrote:
: Are you really suggesting gcc ought to adhere less closely to the
: standard ??
No.
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"It showed a lady, with a fur cap on and a fur stole, sitting upright
and holding out to the spectator a huge fur muff into which the whole
of her forearm had vanished!" --From Franz Kafka's Metamorphosis
------------------------------
From: peter hatch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: need insight on RH 6.0 executable loading problem
Date: Fri, 16 Jul 1999 14:02:09 -0500
Let me embellish this a bit...
peter hatch wrote:
>
> I've got an application (a Smalltalk IDE) that works perfectly fine
> under glibc 2.0 (under RedHat 5.x). When RedHat 6.0 (glibc 2.1) came
> out, we started getting a very bizarr problem.
>
> The application is compiled as a threaded executable, and does all of
> it's own memory management. There is a lot of signal handling as well.
> I've found that an executable compiled on a RH5.2 box has the exact same
> problem as an executable compiled on a RH6.0 box....
>
> At one point during the execution of the program (when the image is
> starting up), there is a call to pthread_sighandler (which I guess is
> new in glibc 2.1 linuxthreads). The stack pointer before this call is
> entered has a "bogus" value (falls within one of our own memory spaces)
> and so the call writes the value of the signal (29-SIGIO) into this
> memory space and causes an attribute of one of the objects in the system
> to be dropped (causing a seg fault when that attribute is accessed).
>
> So, after weeks of looking at this, I'm thuroghly flumoxed. I found
> that if I load the executable's data section at 0x80d49f5 or above
> (instead of the default 0x80cd4e0 or "any" value below 0x80d49f5) the
> application operates as intended.
>
> I also found that the offending call to pthread_sighandler is always
> activated during an Xlib call (while opening a display, in _Xread).
>
But, even though the executable is compiled as a multi-threaded exe,
there are no threads created until a user (programmer) uses our threaded
API to make a system call. At that point, but not before, a thread farm
is created and henceforth managed.
So, the app is technically multi-threaded, but no call to
pthread_create() happens (until the programmer does it). I've tested
our threaded interface in this situation, and it works just fine (even
though the app will still core if this one attribute pointer is
accessed).
> Does anyone have any ideas about this? I'd welcome any input, no matter
> how outlandish it seems :-)
>
> TIA,
> pete
So, if anyone has any ideas I'd sure love to hear them :-) I'm more
than willing to call someone to explain the problem further. This is
kind of a show-stopper :-(
Thanks!
pete
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Makefiles for multiple programmers
Date: 16 Jul 1999 19:25:16 GMT
David T. Blake ([EMAIL PROTECTED]) wrote:
: Try cranking up emacs and browsing the info tree. I know
: emacs is a bloated piece of crap, but it is the best info
: browser I know of.
Uh-oh... UH-OH!! Were you just dissin' emacs? Huh, were you?!?!
"bloated piece of....."?!?! Apparently you'll just have to
learn the hard way, but, if you thought it was unwise to mess
with The Penguin, consider messing with The Gnu!! He'll sit
his bloated butt on you!!! :)
==================================
Emacs programmer's tip o' the day:
M-x grep-find <return>
Run find (like this): find . -type f -exec grep -n {} /dev/null \;
change the stuff in the minibuffer to
find ~/source/path -name "*.[ch]" -exec fgrep -n {} FOO /dev/null \;
then you have a grep-style list of *hyperlinks* to all occurences
of FOO in source files under the subdirectories of ~/source/path.
Very cool!
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"If lightning is the anger of the gods, the gods are concerned mostly
with trees." --Lao Tse
------------------------------
From: Richard Demanowski <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,utah.linux
Subject: RFC 959 linux ftpd, Contivity Extranet Switch
Date: Fri, 16 Jul 1999 19:00:40 GMT
I've found an issue with the Bay Networks Contivity Extranet Switch (a VPN
solution), and the Linux ftpd.
The CES uses an FTP server to load software upgrades. On the Linux
server, the download to the CES dies with a message that it can't get a
directory listing from certain directories.
In the software tree there are several directories which contain no files,
and these are the ones that the CES pukes at.
It works fine from a Solaris and an NT box.
I tried doing an FTP from a client workstation onto the Linux and the Sun
boxes, and did an ls and a dir on an empty directory.
Here's what I got from the Linux box:
ftp> cd empty
250 CWD command successful.
ftp> ls
200 PORT command successful.
diff -> 550 No files found.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
diff -> total 2
drwxr-xr-x 2 nortel users 1024 Jul 16 05:26 .
drwxr-xr-x 9 nortel users 1024 Jul 16 05:26 ..
226 Transfer complete.
126 bytes received in 0.11 seconds (1.15 Kbytes/sec)
Here's what I got from the Sun box:
ftp> cd empty
250 CWD command successful.
ftp> ls
-> 200 PORT command successful.
diff -> 150 ASCII data connection for /bin/ls (167.1.23.126,16644) (0 bytes).
-> 226 ASCII Transfer complete.
ftp> dir
200 PORT command successful.
150 ASCII data connection for /bin/ls (167.1.23.126,16643) (0 bytes).
diff -> total 4
drwxr-xr-x 2 nortel staff 512 Jul 16 09:25 .
drwxr-xr-x 6 nortel staff 512 Jul 16 09:25 ..
226 ASCII Transfer complete.
124 bytes received in 0.02 seconds (6.20 Kbytes/sec)
The difference is that the Linux ftpd responds to the ls request with a
550 File not found, and the Sun ftpd responds with the sequence 150, 226.
The response to the dir request is also different, in that the Linux box
finds 2 files, and the Sun box sais 4.
Looking at RFC 959, page 51, I see that the 150, 226 sequence is a valid
response to a list request. I do not, however, see 550 in the list of
valid responses.
It does not seem to me that 550 would be acceptable, since 5yz indicates
a Permanent Negative Completion, x5z indicates that it's from the file
system, yet a directory listing that contains no file names is still a
perfectly good directory listing.
Does the Linux ftpd not adhere to RFC 959? Is there an updated RFC that I
missed that lists 550 as a valid response to LIST? I could not find any
documents on www.isi.edu that supercede RFC 959 with regard to expected
behaviour from the LIST directive.
Thanx,
RichD
--
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.wasatch.com/~rdemanow/
=========================================================================
"I may disagree with what you have to say, but I will defend, to the
death, your right to say it." -- Voltaire
------------------------------
From: Matthew Carl Schumaker <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: IO Completion Ports
Date: Fri, 16 Jul 1999 15:24:39 -0400
Matthew Carl Schumaker
UPAC Lights Administrative Chairperson
[EMAIL PROTECTED]
veni, vedi, velcro
I came, I saw, I stuck around
On Fri, 16 Jul 1999, Kaz Kylheku wrote:
> On Fri, 16 Jul 1999 14:49:56 -0400, Matthew Carl Schumaker <[EMAIL PROTECTED]>
> wrote:
> >I've been trying to find info about IO completion ports under linux
> >but the only info I have dates back to May of 1998
>
> Linux doesn't have IO completion ports. This is a Windows NT (and possibly
> VAX?) concept.
>
I found some messages in the kernel mailing list about a patch that
implemented IO completion Ports that was the reason why I asked
> >Anybody know if there has been any progress on that front?
>
> In the POSIX world, the rough equivalent is asynchronous I/O, so the question
> would be what the status of *that* is.
>
>
I would prefer not to use the Linux POSIX AIO implementation because (I've
heard/read, I haven't actually looked at the source yet) it does
it in Userspace and spawns multiple threads to do it.
Again I'm not sure about the above
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 19:32:07 GMT
Paul D. Smith ([EMAIL PROTECTED]) wrote:
: %% [EMAIL PROTECTED] (Scott Lanning) writes:
: sl> But who cares what I think...? <sigh>
:
: Apparently not anyone at all, at least in this respect ;).
Typical! :) That's okay, I like to think differently.
: etc. because many compilers didn't support it? There are also
: various hacks that people used to use in place of token pasting (##)
: that sometimes worked and sometimes didn't. Etc. etc. Maybe you're
: too young to remember the Bad Old Days :).
Yes, but I have a copy of the first edition of the GNU C preprocessor
manual! IIRC, it explains the hacks and some other cool ones.
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"Besides a mathematical inclination, an exceptionally good mastery of
one's native tongue is the most vital asset of a competent programmer."
--Edsger Dijkstra
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: DMA from/to user space?
Date: 16 Jul 1999 18:39:30 GMT
In article <[EMAIL PROTECTED]>,
Maciej Golebiewski <[EMAIL PROTECTED]> writes:
> Robert Kaiser wrote:
>
>> IMHO, this kind of functionality should be in the standard kernel.
>> Anything else (patch or module) is a kludge.
>
> I don't know. This (standard part of kernel) is not entirely safe:
> a rogue application might lock a significant part of physical RAM
> and bring the system to its knees.
That's not what I had in mind. I thought of implementing user-space
DMA functions in the kernel as a standard infrastructure for use
by device drivers, not as a system call for use by (potentially
rogue) applications. Of course, one would have to trust the device
drivers using this API to make sure that they won't bring the
system to its knees, but you have to trust device drivers anyway.
BTW, the mlock() system call in it's current form is pretty much
a license to bring the system down the way you describe: each
process is allowed to lock (I think) at most half of the
available physical memory using mlock(), so if you have two or
more rogue processes doing just that ... down the system goes.
(To be fair: This was the case at least for the 2.0.x series
kernels, I haven't checked on the 2.2.x kernels yet)
Things are not quite as bad as this sounds though because mlock()
is a root-only system call and by definition, programs with root
permissions are to be trusted.
Cheers
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: DMA from/to user space?
Date: 16 Jul 1999 18:52:00 GMT
In article <[EMAIL PROTECTED]>,
Maciej Golebiewski <[EMAIL PROTECTED]> writes:
> What about putting this functionality into a separate module? So that
> the next time someone need that, instead of patching the kernel or
> reimplementing the code, it would be enough to use an existing module?
In my experience, putting this code into a module means to
duplicate a lot of code that already exists in the kernel
into that module (with a few *slight* modifications). This
doesn't strike me as a sound approach.
Nevertheless, since so many people seem to be reluctant to patch
their kernel, I might do just that and offer it as an alternative
to my patch -- as soon as I can find the time to do it...
I'm interested in people's feedback on this. Would anyone in this
group prefer such a module-based solution over a kernel patch ?
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: RCS question
Date: 16 Jul 1999 20:05:51 GMT
In article <378a57bc.3205759@news>, <[EMAIL PROTECTED]> wrote:
| I need to know if there is a way to specify the name to lock a source
| file under when checking it out in RCS. It defaults to locking it by
| the login name. I want to circumvent that.
Do you want the lock (as shown by rlog) or the ownership to be set? The
normal way to do this is to let users check out the files as themselves,
rather than faking things, which tends to muddy the audit trail.
I can give you some tricks if you can clarify what you are trying to do.
| Please email me at [EMAIL PROTECTED]
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 19:43:49 GMT
Paul D. Smith ([EMAIL PROTECTED]) wrote:
: "Fixing" this would likely involve some gross, unclean hacks, and no
: one likes a gross, unclean hack. Much simpler to just follow the
: standard and spit an error. After all, the code really _IS_ in error.
Agreed. And they should remove all other instances in which they
do not follow the standard.
: If GCC didn't kick it out, some other compiler very likely would.
: It's simplest to simply fix the broken code and move on.
In fact that's what I would've done, but I didn't want to see
them attack a Cute Panda.. ;)
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"One should not confuse this craving for change and novelty with the
indifference of play which is in its greatest levity at the same time
the most sublime and indeed the only true seriousness." --Georg Hegel
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 16 Jul 1999 20:29:39 GMT
In article <7m8qtt$[EMAIL PROTECTED]>,
Byron A Jeff <[EMAIL PROTECTED]> wrote:
| In article <7m8ju7$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
| >I am using Linux 2.2 kernel. and I see that it still does not support
| >creating a file > 2GB in size.
| >
| >Any one knows when Linux might support real large file sizes?
| >may be in Linux 2.3 ?
|
| If only the kernel needed to be changed to support this, then it would have
| been done long ago. There are at least 4 levels of change required:
|
| 1) An actual filesystem representation change. The structure of the filesystem
| must support large file sizes.
| 2) Changes in the filesystem code of the kernel to support the changes in (1)
| 3) Changes and/or additions to the C library to interface to the changes
| in (2)
| 4) Changes/recompilation or additions to applications to support 3.
Given that 64 bit stuff works fine in 64 bit machines, this would be
relatively easy to add for 32 bits machines. Note the "relatively"
there, I'm not Dilbert's boss saying "anything I don't understand is
easy," but when the 64 bit stuff is already working it's not a rewrite
to do it, the problem lies in data structures being extended and making
64 bits visible to applications which don't expect it.
I'm not sure how much has to be changed, but I suspect the cleanest way
to do it would be to have a bigfile library which provided a 64 bit
offset_t as a long long. It would be visible in lseek and ltell, and in
various stat commands, so a header file would have to go with the
library.
This is neither simple nor trivial, but by using separate system calls
I believe that it could be done with a complete recompile of the
application source, at least for compliant programs.
Some reasons why it would byte many apps include use of long instead of
offset_t for address arithmetic, use of inappropriate format characters
in printf, etc, for reading or displaying offsets, and other similar
bad coding practice. X3J11 provided a way to write portable code, but
blessed few folks bother.
If I were doing it I would get the header file(s) and library ready,
then hack cc a bit to put the proper include directory and library in by
default. That way programs would not require an extra include, not
Makefiles any non-portable changes.
I believe this will be addressed in ext3, as well as many other things.
My opinion that it could be done does not constitute an offer to do it,
or a request that someone else do it ;-)
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (M. Buchenrieder)
Subject: Re: modem still won't work
Date: Fri, 16 Jul 1999 19:11:22 GMT
Ranger <[EMAIL PROTECTED]> writes:
>ok here is the stats : I have a USR faxmodem (standard sportster in an
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
Which one ? There are real Sportster modems and Winmodems.
The PNP version will not work unless being configured with the
isapnptools. Run "pnpdump > /etc/isapnp.conf" , then edit the
resulting file to your likings. Be aware that COM2 aka /dev/ttyS1
is usually an onboard port, unless you disabled it in your system's
BIOS. Put the modem on COM3 aka /dev/ttyS2 with IRQ 10 (if that one
is otherwise unused [check with "cat /proc/interrupts"]).
Michael
--
Michael Buchenrieder * [EMAIL PROTECTED] * http://www.muc.de/~mibu
Lumber Cartel Unit #456 (TINLC) & Official Netscum
Note: If you want me to send you email, don't munge your address.
------------------------------
** 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
******************************
