Linux-Development-Sys Digest #698, Volume #7     Thu, 23 Mar 00 03:13:14 EST

Contents:
  Re: gcc: how to read/write a block (John Brockmeyer)
  Re: Directory File Space Reclaim (John Brockmeyer)
  Re: excepitons in signalhandler (Oliver Bandel)
  Server information ("Jonathan")
  Re: sysctl from with a LKM (John Brockmeyer)
  Re: ncr53c801 stopped working in 2.3.xx (Juergen Pfann)
  Re: compilation problem (Pete Cavender)
  Re: large numbers of open sockets (Martin Redmond)
  Re: Absolute failure of Linux dead ahead? (The Ghost In The Machine)
  Re: excepitons in signalhandler (Kaz Kylheku)
  Re: Absolute failure of Linux dead ahead? (Christopher Browne)
  gcc problems ("[EMAIL PROTECTED]")
  Re: gcc problems (Vilmos Soti)
  Question for Embedded Linux (=?EUC-KR?B?wNPA58iv?=)
  Netproblems on Linux AXP and Win95 (Martin Kahlert)
  Re: Question for Embedded Linux (Anders Larsen)

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

From: John Brockmeyer <[EMAIL PROTECTED]>
Subject: Re: gcc: how to read/write a block
Date: Wed, 22 Mar 2000 19:15:33 -0700

#include <sys/types.h>
#include <unistd.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <linux/unistd.h>
#include <linux/types.h>
#include <stdio.h>
 loff_t llseek(unsigned int fd, loff_t offset, unsigned int whence);
loff_t offset; loff_t result;
main() {    int n,m;
    int fd = open( "/dev/hda5", O_RDWR);
    if (fd<0) fprintf(stderr, "open failed\n");
    result=llseek(fd,offset, SEEK_SET); /* go to a byte location */
    n=read(fd,&buf, 100); /* read some bytes*/
    if(n<0) /* read failed totally*/
    if(n==0)/* either end of file(disk) or interrupted by a signal
    iif(n<100)/* only go part of it */.
     .... modify the data
    result=llseek(fd,-100, SEEK_CUR) /* move back to the same place */
    m=write(fd,&buf, 100); /* write 100 bytes*/
    if(m<0) // failed
    result=llseek(fd,0,SEEK_CUR); // where are we now?
    }
A program using llseek was able to find the last block on a 3.5 gig partition by
binary search. I assume that
this should work for any reasonably large drive.
Do not mount the drive, use it directly.
It seems as though the prototype for
llseek does not show up in the include files, just the deeper level, more
complex
_llseek, which llseek is a front end for.

[EMAIL PROTECTED] wrote:

> Hi,
>  I am desperately trying to find a very simple low level function that
> writes and reads to any part of the hard drive.
>  I have a 2nd, empty, ext2 hard drive mounted to /db/ directory.
>  I am using gnu gcc and cannot use functions such as fopen because it is
> not efficient enough. I need to use the entire hard disk as one big
>  binary; i.e., 50Gb of data.
>  I know how to do this in dos by simply calling the bios routine to
> write or read at any sector on the hard drive, but I would much rather
> stay
>  away from dos ;-)
>  Currently I am looking into the ll_rw_block() function but I have no
> idea if this is the correct or proper function.
>  Thanks for the help in advanced!!
>  Paul.




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

From: John Brockmeyer <[EMAIL PROTECTED]>
Subject: Re: Directory File Space Reclaim
Date: Wed, 22 Mar 2000 19:21:03 -0700

slightly cleaner solution
cd oldone
mkdir ../newone
ln * ../newone
cd  ..; mv oldone oldonex; mv newone oldone; rm -r oldonex

This has only a very small piece of time in which the files are not available

Juergen Heinzl wrote:

> In article <[EMAIL PROTECTED]>, 
>Weiguang Shi wrote:
> >Hi,  there:
> >    As I am reading the filesystem code of 2.0.38, it occurs to me that
> >the file systems (minix and ext2) do not reclaim the directory entries.
> >    When an entry is deleted, the inode number is set to 0. This is
> >simple and efficient. But what if there is a directory with hundreds of
> >thounds of entries at a time gets all the files under it removed? This
> >will  leave the directory file un-shrinked and thus wastes disk space.
> >    Could someone point out I am right or wrong?
>
> You are right, this is common to Unices, but *lo and behold* there is a
> solution so step down from the window-sill again ...
>
> mkdir somewhere
> mv    somewhereelse/* somewhere
> rmdir somewhereelse
> mv    somewhere       somewhereelse
>
> ... minor note, yes, with lots of creations and deletions the search
> time can degrade as directories grow and minor note two, do not touch
> lost+found directories as they need to have a certain size at least.
>
> Cheers,
> Juergen
>
> --
> \ Real name     : J�rgen Heinzl                 \       no flames      /
>  \ EMail Private : [EMAIL PROTECTED] \ send money instead /




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

From: Oliver Bandel <[EMAIL PROTECTED]>
Subject: Re: excepitons in signalhandler
Date: 23 Mar 2000 03:58:42 +0100


[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> Hi all ! 
> I got a problem when i throw an exception in a signalhandler. When i
> force a SIGFPE signal the
> exception in the signalhandler causes an SIGABRT. When i call the
> Signalhandler manuell
> everything works fine. The little testprogramm shows my problem. I hope
> someone cauld give
> me a little hint.  

> pls cc your replies to [EMAIL PROTECTED] 
> Thx 

> #ifdef HAVE_CONFIG_H 
> #include <config.h> 
> #endif 

> #include <iostream.h> 
> #include <stdlib.h> 
> #include <signal.h> 
>   

> void ErrorFunc(int Error); 
> void SignalHandler(int signo); 

> main() 
> {   
>     signal( SIGFPE,    &SignalHandler ); 

You may better use sigaction(2) instead of signal(2).
signal(2) may not implement a reliable signal handling.


Ciao,
   Oliver
-- 
Linux/OSS in der Bundesverwaltung: http://linux.kbst.bund.de/

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

From: "Jonathan" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.help,comp.os.linux.misc
Subject: Server information
Date: Thu, 23 Mar 2000 03:08:46 GMT

Hi,
    We need a new powerful server for our website.  I need some sugestion
for hardwar vendor.  My company is considering using Cubix.  Any one have
been use it?  Thanks in advance.  The following is my company's requirement:

System we need:
1. Load balancing
2. High availability
3. Fault tolerant
4. Fail over
5. Cluster

Software:
1. Turbo Linux cluster server 4.0 (6.0?)
2. Front end using Apache web server and PHP script language
3. Back end using MySQL

Hardware:
1. 2 load balancing server(Celeron)
2. 2 Pentium III single processor board (running Apache and PHP)
3. 2 Dual Pentium III board(running MySQL)

Questions:
1.  If to use RAID, does all systems(boards) share the same RAID or each
computer has its own RAID?
2.  How can we configure second IP under fail over situation?  For example,
one from a dedicated line and other using DSL.  How about DNS?
3.  What is the capacity of such system?
4.  How can we upgrade if needed?




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

From: John Brockmeyer <[EMAIL PROTECTED]>
Subject: Re: sysctl from with a LKM
Date: Wed, 22 Mar 2000 19:46:16 -0700

proc is a tree of structures, you cannot do it all in the name
sys/net/ipv4/stest
instead you need to have the file stest, and have as its parent the proc
directory ipv4, which means
you have to look it up in the kernel source code to get the name of the parent
structure.
\http://search.thetrip.com/corp_travel.html

> I'm using the proc_dir_entry structure in the following fashion:
>
> /* Directory entry */
> static struct proc_dir_entry Our_Proc_File =
>   {
>     0, /* Inode number - ignore, it will be filled by
>         * proc_register[_dynamic] */
>     18, /* Length of the file name */
>     "sys/net/ipv4/stest", /* The file name */
>     S_IFREG | S_IRUGO | S_IWUSR,
>     /* File mode - this is a regular file which
>      * can be read by its owner, its group, and everybody
>      * else. Also, its owner can write to it.
>      *
>      * Actually, this field is just for reference, it's
>      * module_permission that does the actual check. It
>      * could use this field, but in our implementation it
>      * doesn't, for simplicity. */
>     1,  /* Number of links (directories where the
>          * file is referenced) */
>     0, 0,  /* The uid and gid for the file -
>             * we give it to root */
>     0, /* The size of the file reported by ls. */
>     &Inode_Ops_4_Our_Proc_File,
>     /* A pointer to the inode structure for
>      * the file, if we need it. In our case we
>      * do, because we need a write function. */
>     NULL
>     /* The read function for the file. Irrelevant,
>      * because we put it in the inode structure above */
>   };
>
> (Note: The above is modified code from the Kernel_Module_Programming
> document at http://www.nodevice.com)
>
> When I insert the LKM (which calls proc_register() and everything else, of
> course), the file doesn't show up as it's supposed to. It does yield some
> odd behavior, though:
>
> [root@white super]# insmod proctest.o
> [root@white super]# find /proc -name "stest*"
> find: /proc/sys/net/ipv4/stest: No such file or directory
> find: /proc/5144/fd: Permission denied
> [root@white super]# rmmod proctest
> [root@white super]# find /proc -name "stest*"
> find: /proc/5144/fd: Permission denied
> [root@white super]#
>
> What's going on here? It works fine if I try to put the file in /proc, but
> won't work if I try to put it in a subdirectory.
>
> --
> /* Derek Callaway <[EMAIL PROTECTED]> : Programmer; CE Net, Inc. -- S@IRC */
>    char *sites[]={"http://www.freezersearch.com/index.cfm?aff=dhc",
>    "http://www.geekwise.com","http://www.homeworkhelp.org",0};




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

From: Juergen Pfann <[EMAIL PROTECTED]>
Subject: Re: ncr53c801 stopped working in 2.3.xx
Date: Thu, 23 Mar 2000 04:29:38 +0100

Thomas Huber wrote:
> 
> I wanted to try out kernel 2.3.51/2.3.99-pre1 and with both
> my NCR 53C801 SCSI Controller doesn't work any more.
> With Linux-2.2.13 it works like a charm:
> 

Hello, 

I don't really know what 'memory mapped vs. normal i/o' means, 
and if there's a significant change in that for 2.3.51, 
but apart from that, I'd recommend you use the "ncr53c8xx" 
driver instead of "ncr53c7,8xx" - but _not_ the "sym53c8xx".
IMHO the ncr53c8xx is best fitted for your 53c810 (not 801). 
You could then fiddle around with the config options - for 
instance, there is one "Use normal i/o" that seems worth a 
try to enable resp. disable and compare the situation. 
But - are you sure to try out possibly unstable "developer" 
kernels if you use possibly the wrong driver and seem to be 
unable to find a comparatively simple answer yourself in 
documentation (here : kernel config help), which is there 
at least since 2.0.x (just wondering...) ?

Juergen

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

From: [EMAIL PROTECTED] (Pete Cavender)
Subject: Re: compilation problem
Date: Thu, 23 Mar 2000 03:44:07 GMT

In article <[EMAIL PROTECTED]>, "Stewart
Coomb" <[EMAIL PROTECTED]> wrote:

> me

You don't have all the proper PCI headers included...or else you are
trying to LINK your driver....a driver is just a object file, not a linked
executable...I don't have my driver code herel...email me tomorrow when I
am at work if you need more help.


Pete Cavender

[EMAIL PROTECTED]

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

From: Martin Redmond <[EMAIL PROTECTED]>
Subject: Re: large numbers of open sockets
Date: 22 Mar 2000 17:55:35 -0500


http://www.kegel.com/c10k.html has a lot of pointers that may
be of interest to you.  Newer kernels (>2.13.21) have implemented
sigwaitinfo() which will tell you what fd needs a read/write. 
It seems like the best way to go for a large sparse set of 
sockets.

BTW: I'm running a dual 600Mhz with 1Gb mem and it handles 
20k tcp (stream) open sockets well.

Martin

Chris Green <[EMAIL PROTECTED]> writes:
>       Are there going to be any problems with an application
> (running on a large linux system w/ lots of ram and processor amd
> internet connection bandwidth) that might have something like 50K
> simultaneous open stream sockets? Traffic through each socket will be
> fairly low, and intermittent. The app would use poll() to wait for
> requests, and then dispatch the requests to different threads. I know
> I could use some multiplexing scheme w/ udp to get around the huge #
> of connections, but there are good reasons to do it with stream
> sockets, if practical.
> 
>       Posted to this group, because I'm worried about kernel limits,
> or severe performance problems.
> 
> -- 
> Chris Green

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

From: [EMAIL PROTECTED] (The Ghost In The Machine)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Thu, 23 Mar 2000 05:08:21 GMT

In comp.os.linux.advocacy, SetMeUp <[EMAIL PROTECTED]>
wrote on Wed, 22 Mar 2000 19:43:06 GMT
<en9C4.1872$[EMAIL PROTECTED]>:
>> What's wrong with Modula-3?  ;)
>
>   It's wrong that it is not C.

Hmm..."Not C"...um...is that close enough to Godwinize this thread? :-)

Mind you, I do know at least two operating systems (Apollo/DOMAIN Aegis
and older versions of MacOS) which were written in Pascal, or some
variant thereof, so I guess it could work... :-)

-- 
[EMAIL PROTECTED] -- insert random misquote here

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

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: excepitons in signalhandler
Reply-To: [EMAIL PROTECTED]
Date: Thu, 23 Mar 2000 05:16:01 GMT

On 23 Mar 2000 03:58:42 +0100, Oliver Bandel <[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> void ErrorFunc(int Error); 
>> void SignalHandler(int signo); 
>
>> main() 
>> {   
>>     signal( SIGFPE,    &SignalHandler ); 
>
>You may better use sigaction(2) instead of signal(2).
>signal(2) may not implement a reliable signal handling.

The chief problem with signal is that many implemetnations of it do not ensure
that the signal is blocked prior to the entry to the handler, and reset the
handler to the default prior to entry. Thus there is a famous race condition
between that signal happening again, and the handler setting itself up again.

For a synchronous exception like SIGFPE, the plain old signal function is more
than sufficient (at least in a single threaded program). The SIGFPE is not
going to recur before the handler is able to re-install itself. 

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

From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 23 Mar 2000 05:27:45 GMT

Centuries ago, Nostradamus foresaw a time when The Ghost In The
Machine would say: 
>In comp.os.linux.advocacy, SetMeUp <[EMAIL PROTECTED]>
>wrote on Wed, 22 Mar 2000 19:43:06 GMT
><en9C4.1872$[EMAIL PROTECTED]>:
>>> What's wrong with Modula-3?  ;)
>>
>>   It's wrong that it is not C.
>
>Hmm..."Not C"...um...is that close enough to Godwinize this thread? :-)
>
>Mind you, I do know at least two operating systems (Apollo/DOMAIN Aegis
>and older versions of MacOS) which were written in Pascal, or some
>variant thereof, so I guess it could work... :-)

The problem with Pascal, as distinct from the others, is that the
design just wasn't made for anything more than education.

a) It defines a single pass compiler;
b) It provides no way of splitting projects coherently into multiple
   files;
c) The typing system doesn't cope all that well with dynamic arrays.

Extensions have been made, but they were inherently non-standard.

Those *aren't* problems with M3; it *was* designed with the ability to
use it as a systems programming language in mind.  But Kernighan's
critique of Pascal is pretty well-put.
-- 
"Wow! You read  advocacy groups once in a  while, thinking you'll find
the occasional gem, but when you  unearth the Taj Mahal you still have
to stand back and gape a little." -- Paul Phillips <[EMAIL PROTECTED]>
[EMAIL PROTECTED] - - <http://www.hex.net/~cbbrowne/lsf.html>

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

From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux.powerpc,comp.os.linux.development.apps,comp.os.linux.setup
Subject: gcc problems
Date: Thu, 23 Mar 2000 17:30:38 +1100

Hi, 
 I am having trouble with the postgres configure program, which requires gcc
to be able to compile programs. As configure was performing its checks, it
failed when it claimed, 'gcc is not able to compile executables'.
 OK, this is problem number 1.
I didn't know why this was, so I tried to compile a simple printf() to make
sure the compilers really weren't working properly. Then I got an error from
the compiler saying it couldn't find stdio.h. Yes, I did #include <stdio.h>
properly.
 That is problem number 2.
I might add gcc was installed as an rpm, separately from the system
installation, and the required cpp was also installed. I haven't encountered
either of these problems before, could anyone offer some help?
Thanks, Alex.


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

Crossposted-To: 
comp.os.linux.powerpc,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: gcc problems
From: Vilmos Soti <[EMAIL PROTECTED]>
Date: Thu, 23 Mar 2000 07:07:00 GMT

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:

> I didn't know why this was, so I tried to compile a simple printf() to make
> sure the compilers really weren't working properly. Then I got an error from
> the compiler saying it couldn't find stdio.h. Yes, I did #include <stdio.h>
> properly.
>  That is problem number 2.

Do you have stdio.h on your system? Do a

locate stdio.h

On a RH6 machine, it belongs to glibc-devel.

Vilmos

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

From: =?EUC-KR?B?wNPA58iv?= <[EMAIL PROTECTED]>
Subject: Question for Embedded Linux
Date: Thu, 23 Mar 2000 16:15:54 +0900

Hi everyone!
I am interested in Embedded Linux.
I want to run Embeded linux on 860 processor or other popular processor.

Do anybody know to resources (web site, new group, company, source)
related to Embedded Linux development?
Please, teach me.
I have intention to buy a resource.
Thank you for reading my question?




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

From: [EMAIL PROTECTED] (Martin Kahlert)
Crossposted-To: comp.os.linux.networking,comp.os.linux.alpha
Subject: Netproblems on Linux AXP and Win95
Date: 23 Mar 2000 07:58:22 GMT
Reply-To: [EMAIL PROTECTED]

Hi,
I can't get my home network to work.
I have two computers at home:
One is an Alpha Linux box with a 100MB network card which i run
by the tulip driver (I also tried the de4x5 driver with the same
negative results, too).
I placed the neccessary routing entry for eth0 into /etc/route.conf.
And set up the other network tasks like activating eth0.

The other one is a Windows 95 box where i plugged in a 
3com Fast Etherlink XL 3C905B-TX PCI yesterday.
I installed the Winblows drivers and windows has no problems at all
(the hardware manager tells me, the card is ready to work, no conflicts).
Then i installed the M$ TCP/IP driver, told it about its
IP address (192.168.1.2), my gateway 
(i.e. my Linux ALpha machine, 192.168.1.1) and the netmask 255.255.255.0.

If i now do a ping from Win to Linux, i get connection timed out;
the other way round, i get no output at all.

The output of ifconfig eth0 looks reasonable to me,
but every ping increases the value
in the errors entry of the TX packets line.
The driver reports (/var/log/messages), that it negotiated a
100baseFx-FD value for the transmission parameters.
No error output here, either.

There is no HUB in between the 2 machines.

So why on earth, doesn't this thing work, when there is no error, neither
on Linux nor on Win side?

Could anybody give me a hint?
How do i debug the problem - is it on Linux
or on the Windows side?

Thanks in advance for any help,
Martin.

-- 
The early bird gets the worm. If you want something else for       
breakfast, get up later.

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

From: Anders Larsen <[EMAIL PROTECTED]>
Subject: Re: Question for Embedded Linux
Date: Thu, 23 Mar 2000 08:53:15 +0100

=C0=D3=C0=E7=C8=AF wrote:
>
> I am interested in Embedded Linux.
> I want to run Embeded linux on 860 processor or other popular processor=
=2E
> =

> Do anybody know to resources (web site, new group, company, source)
> related to Embedded Linux development?
> Please, teach me.
> I have intention to buy a resource.

You'll find all you need at one of the portals dedicated to embedded Linu=
x:
   http://www.linuxembedded.org/
or
   http://www.embedlinux.net/

There are probably more portals than these, though.

Anders Larsen

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


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