Linux-Development-Sys Digest #168, Volume #7      Tue, 7 Sep 99 19:13:41 EDT

Contents:
  Re: glibc-2.1.1 problems (James R. Van Zandt)
  network block device -- zero bytes? ("Ted Pavlic")
  Re: Problem porting to LINUX (Torsten Poulin)
  Re: Problem porting to LINUX (Kaz Kylheku)
  Re: My opinion on TAO: the ultimate OS (void)
  My opinion on TAO: the ultimate OS ("M van Rooij")
  Re: Stop the VFS from buffering form by ch dev driver (ellis)
  Re: Max threads and TCP connections? (No Spam)
  Re: Max threads and TCP connections? (No Spam)
  Re: My opinion on TAO: the ultimate OS (Donovan Rebbechi)
  gcc compiler error (with tty_io.c) ([EMAIL PROTECTED])
  Re: LispOS? (Dave Love)
  Disk and RAM size for character mode Linux ("Simon Kwan")
  Free bug tracking tool for Linux users and developers ("Yaron Sinai")

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (James R. Van Zandt)
Subject: Re: glibc-2.1.1 problems
Date: 7 Sep 1999 12:30:04 -0400

In article <[EMAIL PROTECTED]>,
Mike Dowling <[EMAIL PROTECTED]> wrote:
...
>
>A second alternative might be to give up doing everything myself, and
>to start using some distribution.  I regard this as being almost as
>time consuming as doing everything myself, as I am unlikely to be
>very satisfied with any distribution, and so would inevitably had to
>start customising everything.

If you do decide on this path eventually, I suggest you try Debian.
It will not necessarily be set up to your liking, but it is set up by
and for the knowledgeable sysadmin, and is very configurable.

                        - Jim Van Zandt


------------------------------

From: "Ted Pavlic" <[EMAIL PROTECTED]>
Subject: network block device -- zero bytes?
Date: Tue, 7 Sep 1999 16:23:04 -0400

I'm trying to use a network block device currently. I've compiled NBD
support into my 2.2.12 client machine. I'm using the latest (so far as I can
tell) server and client. On my server machine I'm loading nbd-server from
inetd. I am currently trying to connect to the server on the command line of
my client machine using the nbd-client. Every time I try to connect the
client to the server, the client reports:

Negotiation: ..size = 0

And nothing in the log file. The server reports this in the logfile:
(daemon.log and info.log)

Sep  7 16:21:10 nw02 nbd-server[18803]: connect from 216.69.192.201
Sep  7 16:21:10 nw02 nbd_server[18803]: connect from 216.69.192.201,
assigned file is /dev/sda1
Sep  7 16:21:10 nw02 nbd_server[18803]: size of exported file/device is 0

The device I'm trying to export is not zero bytes.

/dev/sda1             1        64    514048+  83  Linux

How come both the client and the server keep reporting it as zero bytes? All
programs on the client machine report it (/dev/nd0) as a zero-byte device as
well.

Any ideas? Is there more information I can give that would help?

Thanks for your help. All the best --
Ted



------------------------------

From: Torsten Poulin <[EMAIL PROTECTED]>
Subject: Re: Problem porting to LINUX
Date: Tue, 7 Sep 1999 22:35:26 +0200

Georg S. Lorrig <[EMAIL PROTECTED]> wrote:
> Hello,

> I tried to compile those modules using UWin/DOS (which has a curses
> portation to the windows environment), and it worked fine (just some
> warnings). When I try to compile those modules under Linux (Red Hat 6.0,
> German version using "cc -c C_TEST.C" I get some _hundred_ error
> messages. It seems that cc doesn't like almost any function declaration
> and the like.

C_TEST.C is all caps?  If that is the case, gcc will assume it is a C++
source file due to the .C suffix.  Either rename it to to have .c suffix
or invoke the compiler with the -x c option (should be specified before
the file argument(s)) to force it to accept the source file as C code
regardless of the file name suffix.

-Torsten

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Problem porting to LINUX
Reply-To: [EMAIL PROTECTED]
Date: Tue, 07 Sep 1999 17:07:59 GMT

On Tue, 07 Sep 1999 14:44:29 +0200, Georg S. Lorrig <[EMAIL PROTECTED]> wrote:
>Hello,
>
>a friend of mine asked me to port a small application from a Motorola
>running SystemV to an Intel PC (preferred running Linux). The
>application consists of two C modules that do scren-io (using curses)
>and retrieve pathnames and the like.
>
>I tried to compile those modules using UWin/DOS (which has a curses
>portation to the windows environment), and it worked fine (just some
>warnings). When I try to compile those modules under Linux (Red Hat 6.0,
>German version using "cc -c C_TEST.C" I get some _hundred_ error
>messages. It seems that cc doesn't like almost any function declaration
>and the like.
>
>At that point I'm hopelessly lost, since I have a good understanding of
>COBOL (at least I think so) and some other mainframe languages, but I
>can't solve this problem.
>
>If anyone would have a look at the sources (download them fron
>http://www.lorrig.com/csource.zip) and give me some hints how to get
>this baby running?

First of all, rename the files so they have a .c suffix not .C
because that designates a C++ source file.

Here are some fixes that barely get this compiled. There are still
serious errors that need to be addressed by a C expert.

The most serious problems are relying on the c to be expanded
within quotes in #define CTRL(c) ('c' & 037). This is not how
the ANSI C preprocessing works, but it was supported  in some
traditional compilers. 

There are also a few macro clashes: ncurses claims TTY and CTRL
as macros. This is braindamage on the part of the library.
And some key include files were missing in the second source
file, c_test.c.

I could not test anything because there is no main() function.

I hope you can read diffs. If not, learn.

diff -urNp csource-orig/c_maske.c csource/c_maske.c
--- csource-orig/c_maske.c      Thu Sep 15 10:45:36 1994
+++ csource/c_maske.c   Tue Sep  7 09:46:07 1999
@@ -8,7 +8,7 @@
 #include <fcntl.h>
 #include <time.h>
 #include <signal.h>
-#define CTRL(c) ('c' & 037)
+#define CTL(c) ((c) & 037)     /* CTRL clashes with existing macro */
 #define D_TAB        9
 #define D_ESC       27
 #define D_0         48
@@ -95,11 +95,11 @@ int     c_anz();
 void    c_start();
 void    c_stop();
 void   bscopy();
+int    catch(int);

 void c_start()
 {
-  int catch();
-  int c_term();
+  int  c_term();
   if (c_term(1) < 0) {
       printf("\nc_term: Startfehler");
       exit (1);
@@ -120,7 +120,7 @@ void c_start()
   return;
 }

-int catch()
+int catch(int sig)
 {
 char pfad[30];
 void c_stop();
@@ -870,10 +870,10 @@ int       zeichen1, zeichen2, zeichen3, zeiche
        case KEY_ENTER :
         case '\n' :
        case '\r' :      return(K_ENTER);
-       case CTRL(B) :   return(K_F6);
-       case CTRL(L) :   return(K_F7);
-       case CTRL(P) :   return(K_F8);
-       case CTRL(E) :   return(K_CTRL_E);
+       case CTL('B') :   return(K_F6);
+       case CTL('L') :   return(K_F7);
+       case CTL('P') :   return(K_F8);
+       case CTL('E') :   return(K_CTRL_E);
         case D_TAB   :   return(K_TAB);
        case D_KOMMA :   return(K_PUNKT);
        case D_PUNKT :   return(K_PUNKT);
diff -urNp csource-orig/c_test.c csource/c_test.c
--- csource-orig/c_test.c       Thu Sep 15 10:45:44 1994
+++ csource/c_test.c    Tue Sep  7 09:54:57 1999
@@ -12,7 +12,8 @@
 #include <sys/types.h>
 #include <sys/ipc.h>
 #include <sys/msg.h>
-#define CTRL(c) ('c' & 037)
+#include <termio.h>
+#include <unistd.h>

 void c_init();
 void c_end();
@@ -324,9 +325,9 @@ int station(s1)
 char *s1;
 {
 int i;
-static char TTY[30];
-strcpy(TTY, ttyname(0));
-for (i = 0; i < 12 && TTY[i] != '\0'; i++) s1[i] = TTY[i];
+static char tty[30];
+strcpy(tty, ttyname(0));
+for (i = 0; i < 12 && tty[i] != '\0'; i++) s1[i] = tty[i];
 return(0);
 }



------------------------------

From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: My opinion on TAO: the ultimate OS
Date: 7 Sep 1999 20:42:57 GMT

On 7 Sep 1999 18:58:02 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]>
wrote:
>In comp.os.misc M van Rooij <[EMAIL PROTECTED]> wrote:
>: I just skimped over the website describing the goals of Tao.
>
>hehehe "skimped"? yes many people I run into like to "skimp"

Maybe the universe is trying to tell you that you talk too much.

>rome wasn't built in a day. linux was not built in a day.
>when was linus' 1st post to Usenet anyway? it was close to
>7 years or so to the current date.

I believe Linux was available in a bootable configuration in '91.  So
given that Linus' post must have been at least a bit before that,
you're wrong.

-- 
 Ben

[X] YES! I'm a brain-damaged lemur on crack, and I'd like to
    order your software package for $459.95!

------------------------------

From: "M van Rooij" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: My opinion on TAO: the ultimate OS
Date: Tue, 7 Sep 1999 19:05:38 +0200

I just skimped over the website describing the goals of Tao.

They look like a real challenge to me. One thing is clear (to me at least),
you guys have a long road ahead getting anywhere. I think you should start
out with something simple and easy to understand, being a very basic part of
what you want to make. Then, by discussion etc, make it bigger, better etc
until you reach your goal....(hell, I'm I just describing the way Linux got
made?), well anyway..

I agree upon the idea that the assumption that anything can be seen as a
file (as done in all those unix-es) is a bad idea. Using objects and
collections of objects is better (I don't dare to say superior,
although....)

As for the sandbox security thing...well, I think its a good idea to present
the programmer (a user is just another layer ontop of the application layer
;-)) with an virtual machine instead of the machine itself. This way, an OS
can keep better track of whats going on (get rid of those silly traps for
page faults as an security measure). The VM should provide a mechanism for
preventing CODE (not a user, programmer or whomever) to cause disaster.
Protect a system from harmfull ACTIONS, not people considered
dangerous...Who cares who did it? It's that it happend that counts!

In fact, I'm (too) expressing my ideas into code. The project is called
Autonomous Actors. I hope to present the code (portions that is) to you
guys. For me, that provides a more accessible way of debating whats right
and wrong....

Regards,
Max



------------------------------

From: [EMAIL PROTECTED] (ellis)
Subject: Re: Stop the VFS from buffering form by ch dev driver
Date: 7 Sep 1999 17:54:53 GMT

In article <7qphfc$5he$[EMAIL PROTECTED]>,
David Belius  <[EMAIL PROTECTED]> wrote:
>I am making a charter device driver where the apps
>are supposed to read or write only a couple of bytes
>at a time. But if a do a getc() from a user space 
>app the VFS(i think) starts to buffer upp 4096 bytes
>of data. How can i stop this?(preferably from within
>the device driver)

Use read instead of getc or perhaps using setvbuf on the stream 
to set it to unbuffered.

--
http://www.fnet.net/~ellis/photo/linux.html


------------------------------

From: [EMAIL PROTECTED] (No Spam)
Subject: Re: Max threads and TCP connections?
Date: Tue, 07 Sep 1999 21:32:51 GMT

On Mon, 06 Sep 1999 23:35:48 -0700, Dan McGuirk <[EMAIL PROTECTED]>
wrote:

} Bill LN wrote:
} > Is it possible to maintain 1 million TCP connections from a single
} > Linux box? What would the bandwidth and memory and OS
ramifications be
} > if I try to hold 1 million TCP connections open at once ?
} 
} Well, there's a certain amount of memory that's used just for
accounting
} purposes for each connection.  For example, each connection will
have a
} 'struct sock' allocated for it in the kernel.  IIRC, this structure
is
} about 200 bytes, so for a million connections you're using 200 megs
of
} memory right there.  Each connection will also have both read and
write
} socket buffers; in Linux these are not allocated to a fixed size,
but
} can expand and contract, up to a maximum of 64K in each direction by
} default.  If you have any connections going over high-speed links
with
} large latencies, or you start getting packet loss, or your
application
} doesn't process incoming data quickly, you'll start using up space
in
} these buffers; this can be up to 128K per connection (128 gigs for a
} million connections!).
} 
} To find the socket an incoming TCP packet goes to, Linux uses a hash
} table that by default contains a maximum of 512 buckets.  If you
have a
} million connections, you're going to have to scan through a linked
list
} of about 2000 entries for each packet, which is going to be a huge
} performance hit.
} 
} If you really want to have this many people talking to you at the
same
} time, you should probably use a non-connection-oriented protocol
(UDP),
} and figure out how to deal with packet losses in your application.
} 

Thanks. Its beginning to smell that way.


------------------------------

From: [EMAIL PROTECTED] (No Spam)
Subject: Re: Max threads and TCP connections?
Date: Tue, 07 Sep 1999 21:26:37 GMT

On 7 Sep 1999 07:14:17 -0500, [EMAIL PROTECTED] (Peter
Samuelson) wrote:

} 
}   [Peter Samuelson <[EMAIL PROTECTED]>]
} > > TCP/IP numbers its ports with a 16-bit number, so there's a
limit
} > > of 65,536 ports per protocol (TCP or UDP).  Each client
connection
} > > requires one port, though server connections can share.
} [Kaz Kylheku <[EMAIL PROTECTED]>]
} > TCP connections are identified by four numbers. The source and
} > destination IP and the source and destination port number.  That
} > gives you a vast number of different distinct connections, even if
} > you constrain one endpoint.
} > 
} > In the case of a passive server, all incoming connections share
the
} > same *local* port number and IP. For example, in the case of a
HTTP
} > daemon listening on port 80, all browser connections have port 80
on
} > the server side, and the IP address of the network interface on
which
} > they are arriving.  In principle, there could be much more than
65536
} > such connections, because port numbers are not a problem. Of
course,
} > there couldn't be more than 65536 from any *single* IP.
} > 
} > So running out of port numbers should not be an issue in the case
of
} > *incoming* connections, which is probably what you care about
here.
} > 
} > Of course, any given host can only have so many *outgoing*
} > connections, because normally, each active connection is given a
} > unique ephemeral local port number.  (This restriction could
probably
} > be overcome with some deep hackery.)
} 
} Congratulations for saying in 179 words what took me 31 words.  (:
(:

What i'm talking about is a server listening for incoming connections
on a port or ports and happily (hopefully) accepting 1 million
connections (from machines over internet each with a different IP.

BY outgoing connections above, I assume you mean 64k socket limit for
originating connections from a single machine. Which is not what I'm
worried about.

But what I'm really getting at is comments or thoughts on actually
servicing these 1 million+ connections. Assuming i have infinite
network bandwidth, I still have to have data structures and shit
associated with each of the connections on the server to actually
respond to stuff coming in on them. Additionally, I assume on Linux
each of these TCP connections will use some default TCP window size
which is some number of bytes of buffers. No to mention TCP timers and
other crap.

So 1 million of these suckers cohabitating on one machine (hopefully)
will eat how much memory? Does linux kernel create thread to handle
each TCP connection? what about timers for handling the TCP protocol
itself. Then the big one, I essentailly *can't* simply create a thread
or process to handle each connection do to the shear number. So is
there a way to have an ultra light chunk of C code sit on top of each
connection (perhaps one glorious process with a magic TCPIN and TCPOUT
function) and process incoming data and outgoing data basically in a
callback from TCP without going through thread or other sychronization
object overhead?



------------------------------

From: [EMAIL PROTECTED] (Donovan Rebbechi)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: My opinion on TAO: the ultimate OS
Date: 7 Sep 1999 21:46:19 GMT

On 7 Sep 1999 20:42:57 GMT, void wrote:

>>rome wasn't built in a day. linux was not built in a day.
>>when was linus' 1st post to Usenet anyway? it was close to
>>7 years or so to the current date.

Linus's post was August '91. At this stage, he'd already ported some of 
the GNU stuff ( I think bash and gcc ) 

-- 
Donovan

------------------------------

From: [EMAIL PROTECTED]
Subject: gcc compiler error (with tty_io.c)
Date: Tue, 07 Sep 1999 21:51:54 GMT

Hi

I tried to compile kernel 2.3.15 with atm-0.62,but
got the following error. Can somone give me a hint
what went wrong? More details can be provided if necessary.
Thanks...

Wayne
=====================================================

gcc -D__KERNEL__ -I/root/Linux/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-fno-strength-reduce  -DCPU=586 -march=i586   -c -o tty_io.o tty_io.c
tty_io.c: In function `do_tty_hangup':
tty_io.c:490: internal error--insn does not satisfy its constraints:
(insn 725 724 463 (set (mem/s:QI (plus:SI (reg:SI 1 edx)
                (const_int 293)) 0)
        (reg:QI 5 di)) 51 {*movqi_2} (insn_list 724 (insn_list 679
(nil)))
    (expr_list:REG_DEAD (reg:QI 5 di)
        (nil)))
gcc: Internal compiler error: program cc1 got fatal signal 11


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

------------------------------

From: Dave Love <[EMAIL PROTECTED]>
Crossposted-To: comp.emacs,gnu.emacs,gnu.misc.discuss
Subject: Re: LispOS?
Date: 07 Sep 1999 23:09:52 +0100

>>>>> "CB" == Christopher Browne <[EMAIL PROTECTED]> writes:

 >> Well, how much longer will it be before we can just boot emacs?

 CB> Your mission, if you choose to accept it, is to provide patches to
 CB> emacs and/or gnuclient to permit it to run as one of the Hurd
 CB> servers...

ISTR that some variant of the Rice PLT system was announced to be
bootable on x86.  I don't think I'd want to boot Emacs.

------------------------------

From: "Simon Kwan" <[EMAIL PROTECTED]>
Subject: Disk and RAM size for character mode Linux
Date: Wed, 8 Sep 1999 06:04:29 +0800

Hi Greeting,
  Could anyone please comment on the approximate Disk and RAM size for a
smooth running system with TCP/IP, FTP, Telnet, PPP. The system only need
character mode (no Window graphics, just the plain old shell).
   TIA.  appreciate email reply

Simon



------------------------------

From: "Yaron Sinai" <[EMAIL PROTECTED]>
Subject: Free bug tracking tool for Linux users and developers
Date: Wed, 8 Sep 1999 00:04:17 -0000

Free bug tracking tool.
Helps developers, quality assurance teams and testers to track
and manage bugs and features.
Easy to use - all you need is a browser.

Check it out: http://qadb.com

Yaron




------------------------------


** 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
******************************

Reply via email to