Linux-Development-Sys Digest #323, Volume #8 Tue, 5 Dec 00 02:13:12 EST
Contents:
Re: Please help: NT to Linux port ("Karl Heyes")
Re: Please help: NT to Linux port (Kaelin Colclasure)
Re: Linux Sockets, SendQ buffer problem! (Kaz Kylheku)
Re: Please help: NT to Linux port (Kaz Kylheku)
Re: Development Environments ([EMAIL PROTECTED])
How to make a BIOS call in Linux ([EMAIL PROTECTED])
Re: Module Compilation Problems ("Brian")
Re: Development Environments (rob@_)
Re: Development Environments ("Guy Dillen")
Re: How to make a BIOS call in Linux (Joe Pfeiffer)
Re: Development Environments ("Guy Dillen")
injecting virtual console keystrokes ([EMAIL PROTECTED])
Re: How to make a BIOS call in Linux ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: Please help: NT to Linux port
Date: Mon, 04 Dec 2000 23:25:57 +0000
In article <90gah5$1ab0$[EMAIL PROTECTED]>, "Carlos Portela"
<[EMAIL PROTECTED]> wrote:
>
>
> This code is not being used to catch normal exceptions thrown by the
> code underneath but instead it is being used to catch memory
> protection violations and other exceptions generated by Windows.
>
> My question is:
>
> Is this behaviour of the try-catch pair available in Linux? If not
> then, can you suggest an alternate implementation? In other words,
> how can I obtain control if the code I called (in this case
> CallSomeFunction) screws up?
>
The code follows the C++ standard so yes it will work as long as you
have an uptodate G++, most distros usually will have at least egcs
1.1.2 which seems to be fine for exceptions that I've used. There
may be cases where it may have problems though, haven't seen any!.
The recent versions are 2.95.2. and some class that as out of date,
but I suspect that you will be ok.
karl.
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Re: Please help: NT to Linux port
Date: 04 Dec 2000 15:39:25 -0800
"Karl Heyes" <[EMAIL PROTECTED]> writes:
> In article <90gah5$1ab0$[EMAIL PROTECTED]>, "Carlos Portela"
> <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > This code is not being used to catch normal exceptions thrown by the
> > code underneath but instead it is being used to catch memory
> > protection violations and other exceptions generated by Windows.
> >
> > My question is:
> >
> > Is this behaviour of the try-catch pair available in Linux? If not
> > then, can you suggest an alternate implementation? In other words,
> > how can I obtain control if the code I called (in this case
> > CallSomeFunction) screws up?
> >
>
> The code follows the C++ standard so yes it will work as long as you
> have an uptodate G++, most distros usually will have at least egcs
> 1.1.2 which seems to be fine for exceptions that I've used. There
> may be cases where it may have problems though, haven't seen any!.
> The recent versions are 2.95.2. and some class that as out of date,
> but I suspect that you will be ok.
Actually, I think Carlos is saying that he has code that takes
advantage of NT's Structured Exception Handling (SEH) facility and
asking if that will work under Linux. And the answer is,
unfortunately, "No." SEH is a feature NT has in common with VMS. It's
very cool, very useful, and very non-POSIX. :-(
The way POSIX systems expose this kind of information to user-level
processes is via signals. And, last I knew, you cannot raise a C++
exception in the context of a signal handler. There was some talk /
commentary about supporting this in g++ under certain platforms, but
AFAIK this was never made to work reliably.
-- Kaelin
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.networking
Subject: Re: Linux Sockets, SendQ buffer problem!
Reply-To: [EMAIL PROTECTED]
Date: Tue, 05 Dec 2000 00:13:14 GMT
On Mon, 04 Dec 2000 21:16:42 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>My programmer wrote a TCP test application here to test the connectivity
>and behavior of sudden TCP disconnections between the client and server
>and compiled it for several operating systems including Linux, FreeBSD,
>and windoze. We created this to confirm our results of server apps
>hanging and that there may be a Linux problem associated with this.
So it would appear that Linux has been waiting nine years for your programmer
to find trivial bugs in its TCP stack with his dinky test program. Maybe we
should tell the whole world? Millions of unwitting people are running high
traffic web sites on this thing! :)
>on the freeBSD machine....
>Sending test packet of 4096 bytes to 1 proc(s) ...
>Sending test packet of 4096 bytes to 1 proc(s) ...
>Sending test packet of 4096 bytes to 1 proc(s) ...
>Sending test packet of 4096 bytes to 1 proc(s) ...
>Sending test packet of 4096 bytes to 1 proc(s) ...
>fd(6) Send Fails - dylon.roc.com:4711 disconnecting from 65535. <1>
It seems that FreeBSD's TCP stack sent up a transient error notification.
>The server process realized a disconnect after maybe 20 seconds.
That is not what happened. There is no way to realize a disconnect. All that
your TCP stack knows is that it's not getting a reply from the other side. The
error is just an indication of a retransmission timeout; the connection has not
been closed. You just have a temporary disturbance in the link.
A reasonably designed application implements its own timeouts, rather
than depending on notification from the network layer.
>Here is the netstat sendQ results too.
>
>FreeBSD...
>
>tcp 0 16384 192.22.2.101.65535 192.22.2.47.4711 FIN_WAIT_1
>tcp 0 16384 192.22.2.101.65535 192.22.2.47.4711 FIN_WAIT_1
>tcp 0 16384 192.22.2.101.65535 192.22.2.47.4711 FIN_WAIT_1
That's not surprising since the test program bailed on the error and
closed the socket.
>It seems to disconnect and the sendQ's which are the 16384 column never
>seem to keep increasing which tells me that the server has recognized
>that the client has disconnected.
>
>Linux...
>tcp 0 20480 192.22.2.124:65535 192.22.2.47:4601 ESTABLISHED
Which again is not surprising given that the
>tcp 0 24576 192.22.2.124:65535 192.22.2.47:4601 ESTABLISHED
>tcp 0 28672 192.22.2.124:65535 192.22.2.47:4601 ESTABLISHED
>tcp 0 32768 192.22.2.124:65535 192.22.2.47:4601 ESTABLISHED
>tcp 0 40960 192.22.2.124:65535 192.22.2.47:4601 ESTABLISHED
>etc...
>Up to 56K bytes on the sendQ
>
>*** Once it reaches that 56K mark it just hangs to process!
No, it's *blocking* the process due to inavailability of buffer space. If you
don't want that behavior, then make the socket nonblocking. If the socket fills
up you can use select() or poll() to detect when more room is available.
In a process that handles multiple sockets with one thread, you have to do this
so that no one connection can block that process.
>So it means that the Linux server never realizes that the client went
>away and thus keeps trying to send messages to it.
The FreeBSD implementation will also keep retransmitting messages.
The only difference is that some sort of error was reported.
An application should to implement its own timeout mechanism. Some applications
neet to ignore transient errors (maybe log them somewhere) and keep the
connection open. Communication can resume when the network fixes itself. It's
typically interactive apps that need some sort of timeout, or a way for the
human user to say ``okay that is enough, I don't want wait any more for this
operation to complete''. That's what the stop button is for on your browser.
A properly written networking app cannot bail on the first transient network
error reported on a socket!
>It seems to take a long time for these states to clear up both on
>FreeBSD and Linux. Thus, you can not get the tcpTest server restarted
>until the process is cleared. Is there some way to fix this?
You can set the SO_REUSEADDR option on the socket to allow the port
to be reused for a new listening service.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Please help: NT to Linux port
Reply-To: [EMAIL PROTECTED]
Date: Tue, 05 Dec 2000 00:22:02 GMT
On Mon, 4 Dec 2000 09:45:58 -0500, Carlos Portela <[EMAIL PROTECTED]>
wrote:
>Hi All,
>
>I am porting a server-like product from Windows NT to Linux and I am faced
>with the following code that needs to be implementted under Linux:
>
>try
> {
> CallSomeFunction();
> }
>catch(...)
> {
> // Do something here
> }
>
>This code is not being used to catch normal exceptions thrown by the code
>underneath but instead it is being used to catch memory protection
>violations and other exceptions generated by Windows.
Those violations are generated by bad programming in the application.
The solution is to fix those errors rather than to smooth them over
with exception handling.
C++ exception handling does not catch undefined behaviors in C++, such
as invalid pointer dereferences. According to the C++ standard, which
includes the C standard by normative reference, a bad memory access
may be turned into a SIGSEGV signal being generated. The C standard also
states that if a signal handler is invoked as a result of such a signal,
and it returns, the behavior is undefined.
C++ exception handling is a flow control mechanism like goto or return;
it is most often used to simplify (or complicate) recovery from unexpected
conditions in *correct* programs.
>My question is:
>
>Is this behaviour of the try-catch pair available in Linux? If not then,
>can you suggest an alternate implementation? In other words, how can I
>obtain control if the code I called (in this case CallSomeFunction) screws
>up?
If the function screws up, then your whole program is usually screwed. What you
can do is handle the fatal signal with a handler than then use longjmp() to
return out of the handler without retrying the offending instruction that
triggered the fault.
This approach should only be used, if ever, to trap errors from code which does
not modify any global program state, nor work with any dynamic resources. E.g.
you could use it to recover from a numeric exception in some floating point
code that you can safely clean up, because you know exactly what resources
need to be released and where the global state is at.
------------------------------
From: [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
Subject: Re: Development Environments
Date: 04 Dec 2000 16:52:35 -0600
>>>>> "Guy" == Guy Dillen <[EMAIL PROTECTED]> writes:
Guy> What is/are the most used development environments on Linux for
Guy> database based applications?
Um, can you be more specific about what you think "development
environment" might mean?
Multiple virtual text consoles, one running Emacs, and others running
command shells, represents one of the "most used development
environments."
Did you have some particular development "model" in mind?
--
(concatenate 'string "cbbrowne" "@hex.net")
<http://www.ntlug.org/~cbbrowne/>
The statistics on sanity are that one out of every four Americans is
suffering from some form of mental illness. Think of your three best
friends. If they're okay, then it's you. -- Rita Mae Brown
------------------------------
From: [EMAIL PROTECTED]
Subject: How to make a BIOS call in Linux
Date: Tue, 05 Dec 2000 03:49:25 GMT
Does any body know how to make a BIOS call in linux or point me to an
example in the linux src code? I searched through the linix source code
for "bios' or "BIOS" but did not come up w/ anything useful.
Thanks
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian" <[EMAIL PROTECTED]>
Subject: Re: Module Compilation Problems
Date: Tue, 5 Dec 2000 13:04:07 +0800
Perhaps I'm not doing it the professional way. But it just sounds strange to
me that I have to delete the system files supplied by the distributor in
order to restore the link.
-Brian
"Peter T. Breuer" <[EMAIL PROTECTED]> ���g��l��
news:[EMAIL PROTECTED]...
> Brian <[EMAIL PROTECTED]> wrote:
> > The directory /usr/include/linux is a real one containing lots of header
> > files in RedHat 7.0. You cannot directly restore the link. I don't know
why
> > RedHat made this reconstruction, but I think it's better to keep it
there.
>
> Why do you think so? It's wrong. The directory is only there to give
> you some kernel header files in case you don't have any. But he has
> plenty, and he can link to them all. And thus avoid gdoing kernel
> compilatuons that don't work because the right sources are mixed with
> the wrong headers.
>
> In favour of RH's horrible arrangement, it makes it easier to maintain
> several kernel trees at once in an independent manner. But I don't
> care, because I always point /usr/src/linux at whichever one I happen
> to be compiling at the mo.
>
> Peter
------------------------------
From: rob@_ <[EMAIL PROTECTED]>
Subject: Re: Development Environments
Date: 4 Dec 2000 20:35:39 -0800
In article <90h2f3$een$[EMAIL PROTECTED]>, "Guy says...
>
>What is/are the most used development environments on Linux for database
>based applications?
>
IMHO, anyone not using J2EE for database application is making
a huge mistake.
Java was born to be used for Database applications. check out
JDBC 2.0.
As for the Java development on Linux itself, you can use either
IBM JDK or SUN JDK. You can use JBuilder from Borland for the
IDE, or use something as simple as emacs/vi/Makefiles. (I think
JBuilder is the best).
Rob
------------------------------
From: "Guy Dillen" <[EMAIL PROTECTED]>
Subject: Re: Development Environments
Date: Tue, 5 Dec 2000 07:44:11 +0100
thanks for the info.
What about the productivity when using Java (fe. JBuilder)?
What is your idea about "high-level tools" like Omnis, or similar?
"rob@_" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <90h2f3$een$[EMAIL PROTECTED]>, "Guy says...
> >
>
> >What is/are the most used development environments on Linux for database
> >based applications?
> >
>
> IMHO, anyone not using J2EE for database application is making
> a huge mistake.
>
> Java was born to be used for Database applications. check out
> JDBC 2.0.
>
> As for the Java development on Linux itself, you can use either
> IBM JDK or SUN JDK. You can use JBuilder from Borland for the
> IDE, or use something as simple as emacs/vi/Makefiles. (I think
> JBuilder is the best).
>
>
> Rob
>
------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Re: How to make a BIOS call in Linux
Date: 04 Dec 2000 23:19:23 -0700
[EMAIL PROTECTED] writes:
> Does any body know how to make a BIOS call in linux or point me to an
> example in the linux src code? I searched through the linix source code
> for "bios' or "BIOS" but did not come up w/ anything useful.
This is the sort of answer I personally find extremely annoying, but:
You almost certainly don't want to do it. Only a vanishingly small
number of system-style programs, like the boot loader or APM, have any
need to ever look at the BIOS.
If you have to ask how (and I'd have to hunt a while, myself --
speaking as somebody who's written a modularized device driver), it's
a virtual certainty that you don't need to.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
VL 2000 Homepage: http://www.cs.orst.edu/~burnett/vl2000/
------------------------------
From: "Guy Dillen" <[EMAIL PROTECTED]>
Subject: Re: Development Environments
Date: Tue, 5 Dec 2000 07:45:23 +0100
With development environmet i mean in fact an IDE. Where you have high
productivity when developing applications. These application needs to run in
character-based mode as well GUI mode.
Guy
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >>>>> "Guy" == Guy Dillen <[EMAIL PROTECTED]> writes:
> Guy> What is/are the most used development environments on Linux for
> Guy> database based applications?
>
> Um, can you be more specific about what you think "development
> environment" might mean?
>
> Multiple virtual text consoles, one running Emacs, and others running
> command shells, represents one of the "most used development
> environments."
>
> Did you have some particular development "model" in mind?
> --
> (concatenate 'string "cbbrowne" "@hex.net")
> <http://www.ntlug.org/~cbbrowne/>
> The statistics on sanity are that one out of every four Americans is
> suffering from some form of mental illness. Think of your three best
> friends. If they're okay, then it's you. -- Rita Mae Brown
------------------------------
From: [EMAIL PROTECTED]
Subject: injecting virtual console keystrokes
Date: Tue, 05 Dec 2000 06:47:48 -0000
I've looked in the kernel source, and it looks like it should be
very easy to inject at least a few ASCII input characters into a
virtual console tty. There are some escape sequences that cause
responses to come back, and what they do seems rather easy. So
my thought is I could add a new ioctl call where the argument is
a string of characters to be injected. It doesn't look like it
would be very much code, either, since the important stuff seems
to all be there already.
Although I believe I can just do this, I'm intersted in feedback
about variations or alternatives you think may be more helpful
to others and/or would increase the likelihood of being rolled
into the official kernel source.
Any particular ioctl symbol you think I should use?
Should I test to make sure it isn't used for minor numbers beyond
the 0-63 or 1-63 range?
Any limits I should place on size of data, or even data content?
Any security issues you can see?
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to make a BIOS call in Linux
Date: Tue, 05 Dec 2000 06:53:15 -0000
On Tue, 05 Dec 2000 03:49:25 GMT [EMAIL PROTECTED] wrote:
| Does any body know how to make a BIOS call in linux or point me to an
| example in the linux src code? I searched through the linix source code
| for "bios' or "BIOS" but did not come up w/ anything useful.
The kernel operates in "protected mode". The BIOS operates in
"real mode". The CPU behaves very differently in these modes.
I would not say this could not be done, but it would be very
messy. You'd have to create a virtual "real mode" to run the
BIOS call inside of, or literally switch the whole CPU between
modes and back again (major issues include what mode a given
interrupt needs to be handled in).
This is sufficiently a big enough and complex enough task that
I would suggest examine ways to do what you want to do without
using the BIOS.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
** 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
******************************
