Linux-Development-Sys Digest #135, Volume #8     Sun, 10 Sep 00 18:13:15 EDT

Contents:
  Re: Installing Win98, Win2000 and Linux on one PC?! (noodlez)
  Re: Shared libs question (Szabolcs Csetey)
  Re: socket beginner: developping inetd subserver (Mario Klebsch)
  Re: purify and memory managers (Tor Arntsen)
  Re: ethernet over non ethernet hardware (Kaz Kylheku)
  problem with expression... (root)
  Re: Memory allocation Strangeness. (Update) (Szabolcs Csetey)
  Re: OFF_T and 64bit Qustation??  (The Ghost In The Machine)
  Re: OFF_T and 64bit Qustation??  (The Ghost In The Machine)
  Re: Problem with fopen under RedHat 6.2 (The Ghost In The Machine)
  Re: Threads on Linux ([EMAIL PROTECTED])
  Re: Wish for a writable ISO-9660 compatible filsystem (Jerry Peters)
  Imation Superdisk (root)
  Re: Memory allocation Strangeness. (Update) ("Tristan Wibberley")

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

From: [EMAIL PROTECTED] (noodlez)
Crossposted-To: alt.os.linux,comp.os.linux.setup,microsoft.public.win2000.applications
Subject: Re: Installing Win98, Win2000 and Linux on one PC?!
Date: Sun, 10 Sep 2000 13:58:46 GMT

don't forget to create a linux swap partition as well as one mounted
as /home .

On Sat, 9 Sep 2000 10:22:42 -0700, "Gene Hill" <[EMAIL PROTECTED]>
wrote:

>What you are proposing won't be hard. The only thing to mention is that you
>must install win2k with FAT32 file system. If you use NTFS, win98 won't be
>able to see that partition.
>Gene
>"Shicheng" <[EMAIL PROTECTED]> wrote in message
>news:8pdk29$pii$[EMAIL PROTECTED]...
>> Hello there,
>> We would like to install Win98, Win2000 and linux (redhat 6.0)
>> three OSs onto our PC. The PC has a 30 GB hard disk, 128 MB memory
>> and a 700 MHz CPU.
>>
>> We would like to have the above three OSs installed; after the
>> installation, we could select one of the three OSs during the boot time,
>> otherwise, the PC will be booted automatically to the default
>> OS (Win 2000 is the default one). Each OS would use one partition,
>> so the three OSs would need three partitions.
>> Apart from these three OS partitions, we may also need to create
>> two more partitions using the remaining space of the disk:
>> one such a partition would be for the storage of linux's data and the
>> other one would be for the data storage for both the Win98 and Win2000
>> OSs; so the last data partition needs to be seen by both the 98 and the
>> 2000 OSs.
>>
>> We would be grateful you could give us some advice on the above.
>>
>> Thanks,
>>
>> Shicheng
>>
>>
>> Sent via Deja.com http://www.deja.com/
>> Before you buy.
>
>

noodlez :: Stampede GNU/Linux :: [EMAIL PROTECTED]
GPG key :: http://www.megahertz.net/pietrzak/gpg.ascii.pubkey.txt
        Fingerprint: 0EE8 0DBB EB08 C472 2EA4  27C1 93AF 0484 9A40 9D9D

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

From: Szabolcs Csetey <[EMAIL PROTECTED]>
Subject: Re: Shared libs question
Date: Sun, 10 Sep 2000 14:32:33 GMT

  MJ Dainty <[EMAIL PROTECTED]> wrote:
> I'm trying to write some code that uses some shared libs via the
> dlopen/sym/... calls. Currently I'm having problems with making use of
> the _init and _fini functions in the lib code, I get...
>
> /tmp/ccaBGSQx.o: In function `_init':
> /tmp/ccaBGSQx.o(.text+0x30): multiple definition of `_init'
> /usr/lib/crti.o(.init+0x0): first defined here
> /tmp/ccaBGSQx.o: In function `_fini':
> /tmp/ccaBGSQx.o(.text+0x38): multiple definition of `_fini'
> /usr/lib/crti.o(.fini+0x0): first defined here
> collect2: ld returned 1 exit status
....
> gcc -shared -o libname.so foo.c bar.c
> Does anyone know what I'm doing wrong?

Add the -nostdlib or -nostartfiles options as well, see the
gcc man/info pages for more info.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: socket beginner: developping inetd subserver
Date: Sun, 10 Sep 2000 17:55:01 +0200

Pierre Wieser <[EMAIL PROTECTED]> writes:
>[subserver of inetd]
>But I didn't found any responses on two points:

>- how can my server get informations about the client which is sending 
>the message ? (or how can I get a socket when the connection is handled 
>by inetd ?)

You will inherit the socket from inetd as stdin (and as stdout as
well). Information about the client currently connected, can be
retrieved using getpeername(3).

>- how can my server response to the client ? Should it open a new 
>connection or can it response via inetd ?

Since you have the socket as stdout, just write(2) to it.

73, Mario
-- 
Mario Klebsch                                           [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB  1483 30CE 9FB2 A047 9CE0
 Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5  8B98 9464 53FF 9382 F518

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

From: [EMAIL PROTECTED] (Tor Arntsen)
Subject: Re: purify and memory managers
Date: Sun, 10 Sep 2000 16:39:41 GMT

"Paul D. Smith" <[EMAIL PROTECTED]> writes:
>None of these are as easy to use as Purify; since Purify instruments
>your object code you only need to _link_ with it; all the .o's, etc. can
[...]

You don't even have to link with it, you just do 'purify <your_executable>'
and it creates a new file 'your_executable.pure' which you can just execute
directly (or rename it if you want).  At least that's how it works on IRIX.

And yes, it's a great tool.  Much better than e.g. TestCenter, a lookalike
that we tried on AIX for a while.  It never worked as well as Purify so
we abandonded it.

-Tor

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

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: ethernet over non ethernet hardware
Reply-To: [EMAIL PROTECTED]
Date: Sun, 10 Sep 2000 17:03:17 GMT

On Sun, 10 Sep 2000 14:51:45 +0200, Frank Neuber <[EMAIL PROTECTED]> wrote:
>Does anyone know related links (WWW, mailing lists, newsgroups etc) to 
>similar projects e.g ethernet over serial lines.
>Maybe there is a HOWTO or tutorial for this matter?

I have implemented ethernet emulation in the Mobitex radio modem driver.  In a
nutshell, your driver's header building function has to construct the 14 byte
Ethernet MAC headers for outgoing packets. You later thunk them to whatever
format the actual network needs. Similarly, the headers of received packets are
thunked to ethernet format before being handed off to the kernel.  Also when
you register your device, you specify the ethernet arp hardware
type. 

(The reason I did this was to make packet analysis tools like tcpdump work with
the driver).

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

From: root <[EMAIL PROTECTED]>
Subject: problem with expression...
Date: Sun, 10 Sep 2000 22:19:20 -0700

    I am trying to compile an example from the Linux Device Drivers
book.. the following expression gives me this  compile error

     if (current->signal & ~current->blocked)


pipe.c:113: wrong type argument to bit-complement

I know this expression has been replaced with a signal_pending ()
function but I would still like to know
the cause of the error...the version of the kernel is  2.2.12-20smp
(redhat)

Thanks...


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

From: Szabolcs Csetey <[EMAIL PROTECTED]>
Subject: Re: Memory allocation Strangeness. (Update)
Date: Sun, 10 Sep 2000 18:07:33 GMT

  "Tristan Wibberley" <[EMAIL PROTECTED]> wrote:
> Nix <$}xinix{[email protected]> wrote in message
> >"Tristan Wibberley" <[EMAIL PROTECTED]> writes:
> >[memory overcommitment]
> >>                     This is a very serious bug in Linux,
> >Oh, please, let's not start this again. It was thrashed to death on
> >l-k last year :(
> sorry, but it still isn't fixed ;)

There was a patch for it on lkml a while ago, it's a good starting
point ;)
http://lwn.net/2000/0406/a/no-overcommit.html

> >And you really, *really* don't want to turn that off, unless you have
> >dozens of gigabytes or more of swap just lying around to be wasted.

Well, up to now I thought the same but some minimal research revealed
the average needed more (swap disk) space is between 5-60% and the waste
decreases as the allocated swap increases. See the numbers on the
non-overcommiting Solaris OS:
http://x55.deja.com/=dnc/getdoc.xp?AN=501404510

Matthew Dillon, prominent FreeBSD kernel hacker, claimed the reserved
blocks are actually cached swap blocks but I checked and Solaris really
doesn't overcommit memory [think of e.g. high-availability!] or if it
does it hides quite perfectly ;)

Sure, this shouldn't be the exclusive solution but a configurable one
via /proc [as is implemented in the patch above] - I guess quite a lot
of people would victimize cheap disk space for increased reliability.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED] (The Ghost In The Machine)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.portable
Subject: Re: OFF_T and 64bit Qustation?? 
Date: Sun, 10 Sep 2000 19:39:12 GMT

In comp.os.linux.development.apps, Sean Oh
<[EMAIL PROTECTED]>
 wrote
on Sat, 9 Sep 2000 02:17:26 +0900
<zc9u5.15$[EMAIL PROTECTED]>:

[snip]

>r = lseek(fd, 0x100000000, SEEK_SET);

[snip]

I highlight this line in your program because my compiler gave
me a warning on it;

r = lseek(fd, 0x100000000LL, SEEK_SET);

seems to be the correct version, at least as far as gcc is concerned.

(Whether this all actually works, I can't say.  The generated assembly
code looks correct, but I don't have 3 gigabytes of freespace
lying around.)

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

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

From: [EMAIL PROTECTED] (The Ghost In The Machine)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.portable
Subject: Re: OFF_T and 64bit Qustation?? 
Date: Sun, 10 Sep 2000 19:49:42 GMT

In comp.os.linux.development.apps, Sean Oh
<[EMAIL PROTECTED]>
 wrote
on Sat, 9 Sep 2000 02:17:26 +0900
<zc9u5.15$[EMAIL PROTECTED]>:

[snip example]

After further review, I feel like a bit of an idiot, since I
hadn't noticed it was reading from a hard drive.
>From the looks of it, it works fine.  I changed the drive
(I have a large 8 GB SCSI hard drive) so that it's reading
from the drive, not a partition -- all my partitions are < 2 GB
for various reasons, mostly related to my backup media.

Here's my copy of your program, and build instructions.
The modifications should be obvious:

* * *

#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>

static char drive[] = "/dev/sda";

int main()
{
        off_t r;
        int fd;
        int i;
        char buf[1024];

        printf("sizeof off_t= %d\n", sizeof(off_t));
        fd = open(drive, O_RDONLY, 0600);
        if(fd < 0) { perror(drive); return 1; }
        r = read(fd, buf, sizeof(buf));
        printf("read returned = 0x%x\n",r);

        for(i=0;i<32;i++)
                printf("%02x", buf[i] & 0xff);
        printf("\n");

        r = lseek(fd, 0x0100000000LL, SEEK_SET);
        printf("seek returned = 0x%x\n", r);
        r = read(fd, buf, sizeof(buf));
        printf("read returned = 0x%x\n",r);

        for(i=0;i<32;i++)
                printf("%02x", buf[i] & 0xff);
        printf("\n");

        close(fd);
        return 0;
}

* * *

g++ c64.C -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64

* * *

# ./a.out 
sizeof off_t= 8
read returned = 0x400
fc31c08ed88ec0be007cbf0006b90001f3a5beee07b008ea1c060000803c0074
seek returned = 0x0
read returned = 0x400
0000000000000000000000000000000000000000000000000000000000000000
#

* * *

Your data will of course vary, but the two hexdump lines should
be different, as the first one's fetched from the boot block;
the second one is from ... well, who knows what.  (Of course
it will need to run as root.)

I don't specifically know how portable 'LL' is in constants, though.
gcc/g++ probably will like it, but who knows what other compilers think.

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

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

From: [EMAIL PROTECTED] (The Ghost In The Machine)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Problem with fopen under RedHat 6.2
Date: Sun, 10 Sep 2000 19:51:39 GMT

In comp.os.linux.development.apps, Doug Dodson
<[EMAIL PROTECTED]>
 wrote
on Fri, 08 Sep 2000 07:39:24 -0400
<[EMAIL PROTECTED]>:
>This is a multi-part message in MIME format.
>--------------D16B8A998C0BEB58661D4412
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Hi,
>
>We are trying to port some code over to a Linux PC running RedHat 6.2.
>Compilation of the code is fine, however when we run, we get a
>segmentation fault on one of our fopen calls.  We seem to be able to
>pass through the code once, but on the second iteration, we get the
>fault.  This code is being ported from a Solaris machine where it ran
>fine.  Here is the output of "gdb sfg core".  We are just wondering if
>this is a known bug or if anyone has seen behavior like this before.
>Thanks for any help:
>
>GNU gdb 19991004
>Copyright 1998 Free Software Foundation, Inc.
>GDB is free software, covered by the GNU General Public License, and you
>are
>welcome to change it and/or distribute copies of it under certain
>conditions.
>Type "show copying" to see the conditions.
>There is absolutely no warranty for GDB.  Type "show warranty" for
>details.
>This GDB was configured as "i386-redhat-linux"...
>Core was generated by `sfg x w0000001.txt w0000002.txt w0000003.txt
>w0000004.txt w0000005.txt w0001000'.
>Program terminated with signal 11, Segmentation fault.
>Reading symbols from /lib/libc.so.6...done.
>Reading symbols from /lib/ld-linux.so.2...done.
>#0  0x40074709 in chunk_alloc (ar_ptr=0x40109d60, nb=184) at
>malloc.c:2763
>2763    malloc.c: No such file or directory.
>(gdb) where
>#0  0x40074709 in chunk_alloc (ar_ptr=0x40109d60, nb=184) at
>malloc.c:2763
>#1  0x400745ce in __libc_malloc (bytes=176) at malloc.c:2696
>#2  0x4006d83b in _IO_new_fopen (filename=0xbfff9cdc "w0000002.txt",
>    mode=0x8054708 "r") at iofopen.c:42
>#3  0x804c8f0 in oratag ()
>#4  0x8049e60 in main ()
>#5  0x400339cb in __libc_start_main (main=0x8048b0c <main>, argc=992,
>    argv=0xbfffb954, init=0x80487d8 <_init>, fini=0x8053a5c <_fini>,
>    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbfffb94c)
>    at ../sysdeps/generic/libc-start.c:92

You might try something such as Electric Fence (-lefence) to locate
any dynamic allocation errors.

If you have access to it (it's not free!) you can also try
Purify, from Rational Software -- although I don't know if there's
a Linux version or not.

[.sigsnip]

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

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

From: [EMAIL PROTECTED]
Subject: Re: Threads on Linux
Date: Sun, 10 Sep 2000 19:52:47 GMT

Karl Heyes <[EMAIL PROTECTED]> wrote:
>> 1. No threads modify the data segment.
>> 
>> 2. Access to the data segment is authored so they aren't reading the
>> same portion at the same time. (By design of the algorithm, not enforced by
>> locking
>> 

> So, in general you can't!.   The above cases are not typical.

The first is typical of network services, the second is typical of
many matrix operations. They also crop up mix-and matched in various
places in GUIs, IO routines, etc.

Even in the "typical" program, whatever that is, locking is required
for extremly small sections of the whole. By definition, if every load
and store needed to be locked, it wouldn't have been a canidate for a
threaded application.

-- 
Matt Gauthier <[EMAIL PROTECTED]>

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

From: Jerry Peters <[EMAIL PROTECTED]>
Subject: Re: Wish for a writable ISO-9660 compatible filsystem
Crossposted-To: comp.os.linux.misc
Date: Sun, 10 Sep 2000 20:45:38 GMT

In comp.os.linux.development.system fred smith <[EMAIL PROTECTED]> wrote:
> In comp.os.linux.development.system Otto Wyss <[EMAIL PROTECTED]> wrote:
> : While I was reorganizing my backup (using a CD-writer), I had the idea
> : of using an ISO-9660 image file mounted through the loopback device.  I
> : soon had to learn it won't work the way I liked since ISO-9660 is simply
> : readonly. 

> But there's no law that says you MUST use an ISO9660 filesystem on a
> CD! You can write any old filesystem you like, as long as you're willing
> to live with the hit that you can read it only on systems that understand
> that type of filesystem. For example, SCO used to distribute old Skunkware
> CDROMs with one of their own filesystems burned on it.

Yup, just be prepared for _very_ slow access, though. Ext2 is
optimized for a random access disk, not the slow random access of a
cdrom.

        Jerry

> So, you should be able to create, e.g., a EXT2 loopback filesystem, fill
> it up to 650 megs total filesystem size then burn it into a CD. Having
> done that you SHOULD be able to mount it (with "-r") like any other
> EXT2 filesystem.

> : I think it's time Linux gets the ability to use writable image files, so

> I seem to remember seeing that support for UDF is coming, perhaps in the
> 2.4.x kernel? When using a CD-RW medium it allows you to add/erase files
> in a way that seems (at least superficailly) like any other R/W
> filesystem. It works on Windoze (which isn't much of a recommendation, I
> know! :^), so when it becomes supported on Linux you won't really need
> your writable ISO stuff.

> : I'm going to make the following proposition:
> <snip>
> : What are you thinking about my proposition? Could this be done or are
> : there obstacles I don't see. Is it alltogether not necessary, because
> : there's a much better solution?

> I suspect (not having a CD writer on my Linux box, darn it!) that you 
> could simulate what you want without needing a new filesystem, although
> it will cost you some disk space:

> As my suggesiton above, make a loopback EXT2 system, put in it whatever
> you want, add/delete/modify to your heart's content then when ready to
> burn a CD, create an empty ISO filesystem, cp from the EXT2 loopback to
> the ISO loopback and voila!

> Or am I all wet? (be gentle! :^)

> -- 
> ---- Fred Smith -- [EMAIL PROTECTED] ----------------------------
>                        I can do all things through Christ 
>                               who strengthens me.
> ------------------------------ Philippians 4:13 -------------------------------

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

From: root <[EMAIL PROTECTED]>
Subject: Imation Superdisk
Date: Sun, 10 Sep 2000 16:00:50 -0400

Is there a driver for the Imation Parallel superdisk drive anywhere?


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

From: "Tristan Wibberley" <[EMAIL PROTECTED]>
Subject: Re: Memory allocation Strangeness. (Update)
Date: Sun, 10 Sep 2000 22:36:53 +0100


Larry Ebbitt wrote in message <[EMAIL PROTECTED]>...
>Tristan Wibberley wrote:
>> If you need the memory it should actually be there, if you don't, you
>> shouldn't allocate it.
>
>If that's what you want, don't use virtual memory systems, where the
>whole premise is based on jobs allocating more memory than they
>actually use.

I didn't say "use," I said "need." You sometimes *need* to allocate memory
ahead of time to keep performance up - that is acceptable - the software
will just require more concrete memory to be available (concrete memory
being what a VM system abstracts - disk/physical RAM/etc.).

fork() doesn't need over-commit - some applications do. Those ones are
catered for in Linux today, but what about the ones that can't be having
with over-commit (window managers, XFree86, init, (parts of) bash) - they
*cannot* be trusted on Linux.

I'd like to be able to fork and know that the only thing which will take my
memory away is hardware failure - but sometimes I don't care (forking when I
will surely exec and can recover if it fails). If software runs on Linux as
it stands today, it can't know that the memory is there (hardware failure
not-withstanding).

--
Tristan Wibberley



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


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