Linux-Development-Sys Digest #598, Volume #6 Thu, 8 Apr 99 13:14:25 EDT
Contents:
Tools.h++ For Linux ("Stephan Dhaene")
Re: RS485 & Linux: Must toggle DTR quickly (Tommy Thorn)
Re: Templates (Alexander Dymerets)
Re: 4 Gb memory? ECC? (Peter Samuelson)
Re: Yet Another Audio Chip (Emile van bergen)
How to test if /dev/fd0 exists (Phil Howard)
Re: RedHat's X-Windows Requirement (Horst von Brand)
Re: Templates ("RA Scheltema")
Re: PCI DMA to user space possible? (Robert Kaiser)
Re: Nakamichi 5.16S changer hanging in 2.0.36 (Nick Andrew)
Re: Templates ("Martijn Lievaart")
Re: Best chip/method for new PCI card design (Heinz Baier)
signal_pending ??? (Vincent)
Re: How to test if /dev/fd0 exists (Andreas Peetz)
SMP Linux, Any Catches? ("Clint Byrum")
Re: Parallel port access problem in c ("Becker, Frank (CREST:1N42:EXCH)")
Re: RS485 & Linux: Must toggle DTR quickly ("Sergio Tanzilli")
Re: Sockets? connect? ([EMAIL PROTECTED])
Re: Stream Processing (provided by SVR4) for Linux? ("G. Sumner Hayes")
Re: crypt ("G. Sumner Hayes")
Re: Tools.h++ For Linux (Rich Mulvey)
----------------------------------------------------------------------------
From: "Stephan Dhaene" <[EMAIL PROTECTED]>
Subject: Tools.h++ For Linux
Date: Thu, 8 Apr 1999 11:15:36 +0200
Hi,
I was just wondering whether there is something like Roguewave's Tools.h++
for Linux? Is someone using STL or anything?
Anybody clues?
Thanks
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Stephan Dhaene
_/ Lucent Technologies Network Systems - Belgium
_/ Communications Software
_/ Twee Stationstraat 87, B-1070 Brussels, Belgium (EU)
_/ TEL: +32-(0)2-556.74.72 mail: [EMAIL PROTECTED]
_/
_/ I am immortal, so far...
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
------------------------------
From: Tommy Thorn <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded
Subject: Re: RS485 & Linux: Must toggle DTR quickly
Date: 08 Apr 1999 10:02:58 +0200
Olav Woelfelschneider <[EMAIL PROTECTED]> writes:
> Anyway, I did it in software by writing my own driver which bangs directly
> on the uart, listens to its echo and turns the driver off as soon as
> all bytes came back. Timeouts ensure that nothing hangs in the process.
>
> As a bonus, this approach does also collision detection.
Two (possible ignorant) questions:
1) Do you turn it off after *each* char sent, or only the last char
in a packet?
2) Has anyone written a RS485 kernel-level driver for Linux that they
would share?
Thanks,
/Tommy
------------------------------
From: Alexander Dymerets <[EMAIL PROTECTED]>
Crossposted-To:
alt.linux,alt.os.linux,comp.lang.c++,comp.os.linux.development.apps,comp.unix.programmer,comp.unix.questions,gnu.g++.help,gnu.gcc.help
Subject: Re: Templates
Date: Thu, 08 Apr 1999 10:23:58 +0300
Hi!
> I'm trying to design template classes in C++ (under Linux and Solaris) using
> the gcc compiler, but I'm running into trouble. It seems that the template
> functions must be written
> within the header (.h) file. Whenever they are written in the .cpp file I
> get errors about them not being there.
All functions in template classes must be inline.
Alexander
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: 4 Gb memory? ECC?
Date: 8 Apr 1999 02:48:20 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[me]
> > The Right Way to fix this would be the same as the Right Way to fix
> > the ISA DMA 16MB problem on PC's: if you detect that you've got
> > more than 4GB of memory, preallocate something early
[Andy Isaacson <[EMAIL PROTECTED]>]
> That is one solution. The problem is, drivers for PCI devices don't
> differentiate in the kalloc() call between internal buffers and ones
> which will be DMAed into. So this solution will require modifications
> to every driver which does DMA.
Yes, but it's still the Right Way to do it. (: It would take time to do
the manual s/kalloc/pci_malloc/g but I can't imagine it would take
*that* much time. Also, since the change fixes a bug that in practice
will rarely show up in current configurations, arguably it would be
pretty low-priority -- not something you have to do all at once. In
this respect it would be much like the jiffies wraparound fixes Alan
Cox keeps finding, the ones that have made a steady stream from -ac
kernels into Linus's tree ever since fairly late in the 2.1.x game.
Come to think of it, there's a variation on my Right Way. Linux could
have the separate pci_malloc() function but instead of letting
preallocated memory sit there it could make it available for read-only
buffer cache, so that it doesn't go to waste yet is easy to get back if
there isn't a large enough chunk of eligible memory available. That
way the only time you're wasting that memory is in the rather unlikely
scenario of extremely small texts executing with extremely large heaps.
> The Right Way would be to use PCI devices which support 64-bit
> addresses. Does 64-bit PCI require support for 64-bit addresses, or
> does it simply concern the width of the data bus?
Dunno. But either way it would be nice to support "legacy" devices in
big machines, since most current PCI devices are not, in fact, 64-bit.
For many devices, I'm guessing, there is no real need for the
performance increase of a 64-bit bus.
> Lacking that, it would be interesting to know how other vendors (Sun,
> SGI, Digital^WCompaq) have solved this problem.
Yeah. Our F50 -- a relatively low-end RS/6000 server -- has room for
32 DIMMs (I think, I'm not going to open it up right now), meaning at
least 4GB. Surely IBM has addressed (no pun intended) this issue for
AIX....
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: Yet Another Audio Chip
Date: Thu, 8 Apr 1999 11:28:34 +0200
On Wed, 7 Apr 1999, D. C. Sessions wrote:
>However, (and I hope this is a difference) all of the
>management I've been able to buttonhole are OK with
>releasing the specs -- or at least the ones that don't
>have QSound proprietary IP in them. An NDA with
>QSound would of course solve that too.
But... if there would be a driver implemented using that information in
the NDA, and the source is released (of course, as drivers are _part_ of
the GPL'ed Linux kernel), wouldn't this violate the NDA?? Exactly how is
this solved?
If you are proposing a kernel module that is only distributed in its
binary form, forget about it. I for one really, really hate just
injecting any Unidentifiable Binary Object into kernel space, thank you.
Apart from that, one kernel upgrade and it may not work anymore.
What do you think??
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: How to test if /dev/fd0 exists
Date: Thu, 08 Apr 1999 09:40:28 GMT
I need to test to see if /dev/fd0 exists or not. Not the node file,
not the driver, I mean the actual physical device. What happens when
I try to read from /dev/fd0 when no floppy drive exists, it just
hangs, with error messages coming out periodically. Since I will
be doing this during bootup, I certainly don't want things hanging.
I will be doing this in a C program, so if there is a system call
or ioctl than I can do to test for the existance of the drive, that
would be what I need.
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Horst von Brand)
Subject: Re: RedHat's X-Windows Requirement
Date: 8 Apr 1999 10:11:57 GMT
In article <7eh0cj$k1k$[EMAIL PROTECTED]>, Peter Samuelson wrote:
[...]
>Well, I think the whole thing could easily be solved in the same way
>Debian solves the same issue for svgalib. They provide a package,
>"svgalib-dummy", which installs a small libvga.so that just has empty
>symbols in it. That way if your package has a svgalib mode that you
>never use, the dynamic linker will resolve all the symbols and not
>complain, and you don't have to install svgalib.
Why not just install the emacs without X binaries? Or compile emacs without
X yourself?
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vi�a del Mar, Chile +56 32 672616
------------------------------
From: "RA Scheltema" <[EMAIL PROTECTED]>
Crossposted-To:
alt.linux,alt.os.linux,comp.lang.c++,comp.os.linux.development.apps,comp.unix.programmer,comp.unix.questions,gnu.g++.help,gnu.gcc.help
Subject: Re: Templates
Date: Thu, 8 Apr 1999 08:48:23 +0100
Templates are implemented in kind of a funny way. The compiler has to know
on compile-time which instances of the template it is going to use. For
example:
template<class T>
class Array {
public:
Array(int size);
~Array();
private:
T *a;
};
#include "Array.cpp"
void main() {
Array<char> chars;
Array<int> ints;
}
The compiler makes two instances of the Array-class in this example (one for
the chars and one for the ints). In both instances proprietary code is added
for the template T to make the thing work. In order to do this the compiler
has to know how the functions are implemented. When you would have made
object-files (normal procedure) the compiler doesn't know how to do the
replace, since it doesn't know anything when you're making the object-files.
The above example shows the, more or less, right way to work with templates
(STL for example doesn't work like this, but that's spaghetti-code). Just
make a header and source-file in the normal way, but include the source-file
in the header-file and don't make an object-file.
Hope this helps.
Richard Scheltema
Steven D. Nakhla wrote in message ...
>I'm trying to design template classes in C++ (under Linux and Solaris)
using
>the gcc compiler, but I'm running into trouble. It seems that the template
>functions must be written
>within the header (.h) file. Whenever they are written in the .cpp file I
>get errors about them not being there. Is there any way around this? Can
I
>send a flag to the compiler or anything to get them implemented correctly?
>
>
>Please reply to:
>
>Steve Nakhla
>[EMAIL PROTECTED]
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: PCI DMA to user space possible?
Date: 8 Apr 1999 09:25:28 GMT
In article <7eg1as$[EMAIL PROTECTED]>,
Mark Hahn <[EMAIL PROTECTED]> writes:
> you've confused DMA (ISA-based, circa 1984, 64K-aligned, sub-16M)
> with basic PCI bus-mastering. there are dozens of drivers
> in the kernel that do the latter, what you want to do.
I don't think he did. The problem is that you can DMA into kernel
space memory (there are indeed dozens of drivers doing that), but
to pass the data to a user-space application, you always have to
do a memory-to-memory copy, just to get the data across the kernel->user
space barrier. If your device does 50MB/s, this causes an unacceptable
(and completely unneccessary) CPU load.
This was a major drawback for me when I wrote my first Linux driver.
Any other UNIX-style OS I have written drivers for can do this, and,
in fact, adding this capability to Linux isn't hard (see my other
response in this thread).
> there is no good excuse to use NT ;)
Agreed.
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: [EMAIL PROTECTED] (Nick Andrew)
Crossposted-To: comp.os.linux.hardware
Subject: Re: Nakamichi 5.16S changer hanging in 2.0.36
Date: 8 Apr 1999 21:32:03 +1000
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (John Ioannidis) writes:
>I'm running Red Hat 5.2 with the 2.0.36 kernel straight out of the
>box, on a Pentium-II machine with an Adaptec 2940UW, which has a
>Nakamichi 5.16S cd changer and a Seagate 2G Barracuda hanging off it.
I have a box with about 6 Nakamichi changers connected. But that's a
story for another day.
>The five LUNs of the Nakamichi correctly appear as /dev/scd0 through
>/dev/scd4. When I have more than one mounted, what will frequently
>happen is that the system will hang when I try to access the CD that
>is not currently in the reader slot. "Hang" in this case means that
>the display/keyboard/mouse are not responding, but the machine is
>accepting pings and tcp connections (although it won't fork to give a
>login prompt).
A long time ago in a galaxy far away I had this problem with another
CD changer unit. I solved it by patching the SCSI (or CD-ROM) device
driver to increase the read timeout.
I don't think my box hung though; it probably emitted console messages
if the read operation (on the changed device) timed out.
Nick.
--
Zeta Internet SP4 Fax: +61-2-9233-6545 Voice: 9231-9400
G.P.O. Box 3400, Sydney NSW 1043 http://www.zeta.org.au/
------------------------------
From: "Martijn Lievaart" <[EMAIL PROTECTED]>
Crossposted-To:
alt.linux,alt.os.linux,comp.lang.c++,comp.os.linux.development.apps,comp.unix.programmer,comp.unix.questions,gnu.g++.help,gnu.gcc.help
Subject: Re: Templates
Date: 8 Apr 1999 12:38:03 GMT
Alexander Dymerets wrote in message <[EMAIL PROTECTED]>...
>Hi!
>> I'm trying to design template classes in C++ (under Linux and Solaris)
using
>> the gcc compiler, but I'm running into trouble. It seems that the
template
>> functions must be written
>> within the header (.h) file. Whenever they are written in the .cpp file
I
>> get errors about them not being there.
>
>All functions in template classes must be inline.
Apart from some bugs in some compilers, this is simply not true. It is the
most portable though.
Martijn
--
My reply-to address is intentionally set to /dev/null
reply to mlievaart at orion in nl
------------------------------
From: Heinz Baier <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Best chip/method for new PCI card design
Date: Thu, 08 Apr 1999 13:34:57 +0200
I used very succesful Altera FPGA` s for PCI designs. Altera offers a Macro,
called PCI_B, which handles all the PCI interface stuff. It even supports the
so called Burst Mode.
I achieved data rates up to 50 MB/s for Burst transfers (OS AIX).
You can build all your custom logic into the same FPGA.
Gregory Benjamin wrote:
> I'm in the early stages of designing a PCI card
> for a laser film recorder (LFR) device. I have never
> designed a PCI card or written a Linux driver, but
> I have both designed hardware and written low-level
> RTOS code for several processors over the years.
> I want to produce a board design that works well on
> the first try, or failing that, with minimal rework.
> Volume will be low, so PCI interfaces in the form of
> an IP core in an FPGA are probably out. The
> computer system is dedicated to driving the LFR and
> doing simple queue management. What I'm looking for
> are recommendations on the most appropriate vendor/chip
> for the PCI interface, the cleanest buffering/FIFOing
> architecture that will assure me of no data loss, and
> pointers on the most appropriate driver sources to use
> as a starting point. I am also interested in inexpensive
> (<$500) PCI development boards/tools to allow prototyping.
> I have some familiarity with product offerings from
> AMCC, Anchorchips, PLX, etc.
>
> Here are some particulars:
>
> # Laserlab LFR PCI design
>
> o device is a high-resolution laser film recorder (LFR)
> o LFR is controlled by a dedicated PC
> o PC will run Linux (no support for other OSes planned)
>
> o PC configuration
> - ASUS P2B mainboard
> - Intel CPU >= 366MHz.
> - 128MB RAM
> - Matrox G200 graphics adapter
> - UDMA IDE disk(s) attached to mainboard
> - 10/100 mbit/sec NIC
> - LFR PCI card
>
> o LFR charcteristics
> - synchronous device -- data MUST be present when needed
> - data processed as scan lines
> - two scan line periods: 2.5 and 5.0 ms
> - 5 Kilobytes per 2.5 ms scan line
> ( 400 scans/sec * 5KB/line = 2MB/sec)
> - 10 Kilobytes per 5.0 ms scan line
> ( 200 scans/sec * 10KB/line = 2MB/sec)
> - image takes up to 8 minutes, 40 seconds to produce
> - image size 1040 Megabytes (maximum)
>
> o LFR PCI card requirements
> -- outbound data rate 2 megabytes/sec
> -- inbound data rate < 100 kilobytes/sec
>
> o Data flow
> -- receive from NIC via tcp/ip
> -- save to disk as sequence of files
> -- read from disk to RAM
> -- minimally process in RAM
> -- output to LFR PCI card
>
> All input appreciated!
> o-----------------------------------------------------------------------o
> | Gregory Benjamin Laserlab, Inc. o Laser photoplotting |
> | [EMAIL PROTECTED] 6790 Top Gun Street o CNC machining |
> | Suite 9 o Chemical milling |
> | San Diego, CA 92121 o Printed Circuit Fabrication |
> | www.laserlab.com Tel: 619-646-7660 o Precision photomasks |
> | ftp.laserlab.com Fax: 619-646-7667 o AutoCAD to Gerber conversion|
> o-----------------------------------------------------------------------o
------------------------------
From: Vincent <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.x,alt.os.linux,alt.linux,comp.os.linux.development.apps,comp.os.linux.development,comp.os.linux.hardware
Subject: signal_pending ???
Date: Thu, 08 Apr 1999 14:34:54 +0200
I have a program which use the signal_pending function. What is this
function ?
In my version of Linux (SuSE 6.0) it isn't in the kernel source. Is it
obsolete or what other function remplace it ?
[EMAIL PROTECTED]
------------------------------
From: Andreas Peetz <[EMAIL PROTECTED]>
Subject: Re: How to test if /dev/fd0 exists
Date: 8 Apr 1999 14:45:09 GMT
You could test if the block device fd is listed
in /proc/devices. In case floppy-support is build
as a module you may want to do a "modprobe floppy"
before this.
- Andreas
Phil Howard wrote:
>
> I need to test to see if /dev/fd0 exists or not. Not the node file,
> not the driver, I mean the actual physical device. What happens when
>
> [...]
> --
> Phil Howard KA9WGN
> [EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: "Clint Byrum" <[EMAIL PROTECTED]>
Subject: SMP Linux, Any Catches?
Date: Thu, 8 Apr 1999 09:03:15 -0700
We have a system which we are porting to Linux from NT/HP-UX/AIX. All of the
aforementioned handle Multiprocessing extremely well(ok, two of the
aforementioned). Will Linux handle 200-300 user telnet/serial getty
connections well with 2 or 4 processors(Xeon 450's) and a Hardware RAID? I
would like to make sure so we can throw NT out the door. Currently we have
to go with HP or IBM for anything higher than 100 users.
Also, we are tied to RedHat for our database.
------------------------------
From: "Becker, Frank (CREST:1N42:EXCH)" <[EMAIL PROTECTED]>
Subject: Re: Parallel port access problem in c
Date: Thu, 08 Apr 1999 07:50:10 -0700
Reply-To: [EMAIL PROTECTED]
Hi,
you need to give yourself permission to access the port:
ioperm( 0x378 /*start port*/, 1 /*num ports*/, 1)
I don't remember what the last parameter does (no Linux
system nearby...*sob*). Check the man page for more details.
Frank.
------------------------------
From: "Sergio Tanzilli" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded
Subject: Re: RS485 & Linux: Must toggle DTR quickly
Date: Thu, 8 Apr 1999 14:24:53 +0200
>Posting binaries is generally frowned upon.
Ok, I'm sorry
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Sockets? connect?
Date: Thu, 08 Apr 1999 15:24:45 GMT
Your "connect()" (in the client) has to connect to the address of the
server. You have it hard-coded to use "name.sin_addr.s_addr=INADDR_ANY".
This should be the address of the server, as returned by gethostbyname(),
and never INADDR_ANY (except for in the server's code).
-Mark Taylor
[EMAIL PROTECTED]
Revolutionary Server Software http://www.netmax.com/
In article <[EMAIL PROTECTED]>,
Papa Aquilino <[EMAIL PROTECTED]> wrote:
> This is a multi-part message in MIME format.
> --------------FEA1D1AD030EA2529CD956E0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> I want to connect to process throw a network TCP/IP (ethernet). I
> Attached
> two programs in that mail: server.c & client.c.
>
> Those programs work GOOD when I execute both in the same computer. But
> when I
> try to execute the programs in diferents computers the program client
> says:
>
> Connection refused
>
> Because: function connect ( ... ) return -1
>
> Could someone help me please? Thanks to read my message.
>
> Please replay to : [EMAIL PROTECTED]
> ____________________________
> Enrique Cespedes Sanchez.
> e-mail: [EMAIL PROTECTED]
> Almeria.(Spain)
>
> --------------FEA1D1AD030EA2529CD956E0
> Content-Type: text/plain; charset=us-ascii; name="cient.c"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline; filename="cient.c"
>
> #include <stdio.h>
> #include <signal.h>
> #include <errno.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <netdb.h>
> #include <arpa/inet.h>
> #include <string.h>
>
> #define BUFFER 40
> #define HOST1 "papa.aquilino"
> #define PUERTO "kike"
>
> extern int errno;
> void error (int n);
> char leer_chr (void);
>
> main ()
> {
> int i;
> char frase[BUFFER],frase2[BUFFER];
> struct hostent *hostrec;
> struct servent *servrec;
> struct sockaddr_in name, addr;
> int retcode, sock, newsock, flag=0;
>
> // Obtener nombre del host local
> if ((hostrec=gethostbyname (HOST1))==NULL)
> error(1);
>
> // Obtener puerto local
> if ((servrec=getservbyname(PUERTO,"tcp"))==NULL)
> error(2);
>
> // Crear socket
> if ((sock=socket (AF_INET, SOCK_STREAM,0))==-1)
> error(3);
>
> // Actualizar nombre de socket
> name.sin_port= servrec->s_port;
> name.sin_family=hostrec->h_addrtype;
> name.sin_addr.s_addr=INADDR_ANY;
>
> // Contactar con el servidor
> if ((retcode=connect(sock,&name,sizeof(name)))==-1)
> error(4);
>
> // Receive from Server
> if ((retcode=recv(sock,frase,sizeof(char)*BUFFER,flag))==-1)
> error(6);
>
> puts (frase);
>
> strcpy (frase2,"CLIENT: ready");
>
> // Send to Server
> if ((retcode=send(sock,frase2,sizeof(char)*BUFFER,flag))==-1)
> error(5);
>
> }
>
> void error (int n)
> {
> printf ("\nSe ha producido el error %d\n",n);
>
> perror (strerror(errno));
> exit(1);
> }
>
> --------------FEA1D1AD030EA2529CD956E0
> Content-Type: text/plain; charset=us-ascii; name="server.c"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline; filename="server.c"
>
> #include <stdio.h>
> #include <signal.h>
> #include <errno.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <netdb.h>
> #include <arpa/inet.h>
> #include <ctype.h>
>
> #define BUFFER 40
> #define HOST1 "papa.aquilino"
> #define PUERTO "kike"
>
> extern int errno;
>
> inline void error (int n);
>
> main ()
> {
> char frase[BUFFER],fin=0,chr;
> struct hostent *hostrec;
> struct servent *servrec;
> struct sockaddr_in name, addr;
> int retcode, sock, newsock, len=0;
>
> if ((hostrec=gethostbyname (HOST1))==NULL) error(1);
>
> // Get local port -- Obtener puerto local
> if ((servrec=getservbyname(PUERTO,"tcp"))==NULL) error(2);
>
> // Create socket -- Crear socket
> if ((sock=socket (AF_INET, SOCK_STREAM,0))==-1) error(3);
>
> // Actualizar nombre de socket
> name.sin_port= servrec->s_port;
> name.sin_family=hostrec->h_addrtype;
> name.sin_addr.s_addr=INADDR_ANY;
>
> // Enlazar nombre al socket
> if ((retcode=bind(sock,&name,sizeof(name)))==-1)
> {
> close (sock);
> error(4);
> }
>
> // Listen -- Escuchar solicitudes
> if ((retcode=listen(sock,1))==-1)
> error(5);
>
> // Accept -- Aceptar solicitudes
> memset (&addr, 0, sizeof(addr));
> len = sizeof(addr);
> if ((newsock=accept(sock,&addr,&len))==-1)
> error(6);
>
> puts("\nClient found.\n");
>
> strcpy (frase,"SERVER: ready");
> // Send to client
> if (retcode = send(newsock,frase,sizeof(char)*BUFFER,0)==-1) error(9);
>
> // receive from client
> if (retcode = recv(newsock,frase,sizeof(char)*BUFFER,0)==-1) error(7);
>
> puts (frase);
>
> // Close socket
> printf ("\nSERVER: Closing ports: %d, %d\n",sock,newsock);
>
> if (close(newsock)==-1)
> error(8);
>
> if (close(sock)==-1)
> error(8);
>
> }
>
> inline void error (int n)
> {
> printf ("\nSe ha producido el error %d\n",n);
> perror (strerror(errno));
> exit(1);
> }
>
> --------------FEA1D1AD030EA2529CD956E0--
>
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Stream Processing (provided by SVR4) for Linux?
Date: Thu, 08 Apr 1999 12:06:11 -0400
David Grothe wrote:
>
> "G. Sumner Hayes" wrote:
>
> > Others have pointed you at ftp.gcom.com for a STREAMS
> > implementation, but I'd like to note that most of the commercial
> > Unices are moving away from STREAMS back to a socket-based kernel
> > system -- it's just not possible to get decent high-end performance
> > out of STREAMS. They were an interesting experiment, but have been
> > deemed a failure in the eyes
> > of most.
>
> SCO OpenServer uses STREAMS TCP/IP; SCO UnixWare 2.x uses STREAMS
> TCP/IP; SCO UnixWare 7 uses STREAMS TCP/IP; Solaris 2.6 for SPARC (and
> presumably Intel) uses STREAMS TCP/IP. I don't have a Solaris 2.7
> here, but I doubt if it is any different.
Indeed, Solaris is the best illustration of my point. Let me emphasize
that I think the gcom work is quite valuable for supporting existing
STREAMS-based code and obviously not all new development requires
screaming performance. Moving on...
Solaris (in recent versions, certainly 2.6 and later) uses
kernel sockets-based TCP/IP in the fast path and has STREAMS relegated
to secondary status. There is also a TCP/IP-over-streams implementation,
but the kernel sockets are preferred unless you need STREAMS (and the
corresponding performance hit). This is fairly transparent to the
application programmer.
Earlier Solaris development was aimed at having STREAMS be
the primary kernel interface with sockets over STREAMS, but the idea
was trashed precisely because it couldn't perform anywhere near as fast
as the socket-centric solution. (It's of historical interest to note
that kernel sockets were reintroduced at the same time that zero-copy
TCP/IP with hardware checksuming was introduced, but I doubt there's
any real correlation other than that fast networking cards were starting
to deploy and kernels had to do what they could to keep up).
So STREAMS are still there in the kernel, but the motion is away from
them.
Sequent offers a fastlan alternative to STREAMS even though they have
a pretty decent parallel STREAMS implementation; they developed the
fastlan stuff after the fact when it became apparent that STREAMS was
too slow for fast networking. Their TCP/IP is over the fastlan api.
SGI also relegates STREAMS to second-class status, at least in recent
versions (not sure about older versions).
If Sun and SGI can't make it fast and Linus, David, and Alan are against
it, then there's probably something wrong with the idea in the first
place.
If you've got existing STREAMS-based code to port, the gcom stuff is
great; it'd be foolish to rewrite unless the performance issues are
important to your code. If you're developing new code, you're almost
certainly better off forgetting that STREAMS ever existed, IMO.
TLI over sockets seems feasible and cool, and TLI is possibly the
most-used part of STREAMS in practice.
Sumner
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: crypt
Date: Thu, 08 Apr 1999 12:15:00 -0400
Rick wrote:
>
> Where can I find a copy of crypt for linux, binary or source?
Read the README file that comes with glibc. (Or README.crypt at
ftp.gnu.org /pub/gnu/??? (whatever the glibc directory is)).
Crypt comes with all standard Linux distributions -- you need to
use "-lcrypt" on your link line. If you don't have it, you have a
really screwed up system -- the README above should say where to get
it.
--Sumner
------------------------------
From: [EMAIL PROTECTED] (Rich Mulvey)
Subject: Re: Tools.h++ For Linux
Reply-To: [EMAIL PROTECTED]
Date: Thu, 08 Apr 1999 16:27:21 GMT
On Thu, 8 Apr 1999 11:15:36 +0200, Stephan Dhaene <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I was just wondering whether there is something like Roguewave's Tools.h++
>for Linux? Is someone using STL or anything?
Actually, Tools.h++ will build under linux, although it's not an
officially supported platform.
- Rich
--
Rich Mulvey
http://mulvey.dyndns.com
Amateur Radio: aa2ys@wb2wxq.#wny.ny.usa
------------------------------
** 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
******************************
