Subject: Linux-Development Digest #229
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Mon, 26 Sep 94 12:13:16 EDT

Linux-Development Digest #229, Volume #2         Mon, 26 Sep 94 12:13:16 EDT

Contents:
  Problem with using logical partitions (Mihail S. Iotov)
  Re: 1+ Gig SCSI Drives // (Alec Muffett)
  Re: IRC Server for Linux?? (Elmer Joandi)
  Re: Memory in 1.1.50: What is data? (Nicolas BOUGUES)
  Re: Power down idle SCSI disks [w/ kernel patches] (Nicolas BOUGUES)
  Re: Warnings with libc 4.5.26. (Mitchum DSouza)
  Re: more floppy problems with 1.1.51 (Alain Knaff)
  Re: [STATUS] Linus Floppy Driver Development (Alain Knaff)
  Re: ** autoconf.h? ** (Andi Kleen)
  Re: Try this IPX bridging code ... (Rob Janssen)
  Re: Try this IPX bridging code ... (Rob Janssen)
  Re: Building shared libs.. (Mitchum DSouza)
  Re: [?] DIP with auto-redial? (Mike Castle)
  Re: Is there an encrypted filesystem for Linux? (David Wright)
  realtime support planned? (Andre Fachat)
  Re: Linux on CD (Andrej Gabara)
  Re: elf benchmarks (getting closer) (Mitchum DSouza)

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

From: [email-masked] (Mihail S. Iotov)
Crossposted-To: comp.os.linux.misc
Subject: Problem with using logical partitions
Date: 26 Sep 1994 12:09:13 GMT

I had a DOS partition within a DOS partition created bye DOS fdisk and I decided
to change it to linux native and did that with Linux fdisk. But now I can mount
it as either ext2 or msdos ! I did mke2fs before that. I had left the old
fstab entry and upon boot it was mounted as msdos. That does not seem correct tome and may leed to fs corruption.

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

From: [email-masked] (Alec Muffett)
Subject: Re: 1+ Gig SCSI Drives //
Date: 26 Sep 1994 11:43:27 GMT
Reply-To: [email-masked]

In article <[email-masked]>, [email-masked] (Thomas E Zerucha) writes:

>I have noticed that many SCSI drivers don't implement biosparam correctly
>for disks > 1G.  What follows is code that exactly duplicates the Qlogic
>DOS driver's parameter returns.  It is possible that a DOS version of one
>of the older drivers also cannot support >1G drives.  Here is the list:
>
>Drivers that cannot go above 1GB (because they only support 64/32/<1024).
>
>aha152x  aha1740  pas16  t128  wd7000

Funny, I have both a Micropolis 1588 (665Mb) and s Seagate ST12400N
(2.1Gb) hanging off my realio trulio AHA1740.

Moreover, the latter disk is partitioned into two; a 32Mb swap
partition, and "everything else" (approx a 2Gb ext2 partition)

Works just dandy, although fdisk *does* make some funny noises when you
first try to partition the disk... I don't *think* I'm suffering any
sort of weird overflow/wraparound problem yet. I should take it past
the 1Gb barrier this w/e with a new OS install.

so: Any idea how I managed this ?

(possible hint: EISA AHA1740 Enhanced Mode Operation ?)

---
Alec Muffett                      (A Goret is for life, not just for Christmas)
Sun Microsystems 
European Network Security Group
(speaking for himself, not his employers)

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

From: [email-masked] (Elmer Joandi)
Subject: Re: IRC Server for Linux??
Date: 26 Sep 1994 11:00:18 +0200

Bart Kindt ([email-masked]) wrote:
: Hi. Is there a IRC (Internet Relay Chat)  Server available for Linux?

: Any replies by E-Mail please...

Me too. I dream to use it at school with only UUCP connection to internet.

elmer
[email-masked]
-- 
tervitades
elmer
[email-masked]

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

From: [email-masked] (Nicolas BOUGUES)
Subject: Re: Memory in 1.1.50: What is data?
Date: 12 Sep 1994 16:33:48 +0200

Peter Suetterlin ([email-masked]) a ecrit:
: Hi together.

: Just half an hour ago, I compiled the latest 1.1.50 kernel version.
: During bootup, I got the following message:

: Memory: 12956k/16384k available (624k kernel code, 384k reserved, 2420k data)

: So what is the data block? wasn't there in the previous versions, and it
: is 'eating' 2.4 Meg of my memory! I used to have a total of ~15MB.
: Is it a bug or a feature? and if its a feature, what is it doing?

: And, at last, sorry if it's the wrong group, but who if not the
: developers do know about it?

I am experimenting the same problem with the Buslogic driver. It eats ~3Mb of
memory. It is broken (for me) since 1.1.40 or so. I use a Bt 542B rev G.

: Thanks for any info,

:    Peter

:  ----------------------   Peter 'PIT' Suetterlin   -------------------
: |   Kiepenheuer Institut   |   Sternfreunde    | Planetarium Freiburg |
: |   fuer Sonnenphysik      |   Breisgau e.V    |                      |
: |   0761/3198-210          |   0761/71571      |     0761/276099      |
:  [email-masked]

--
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Nicolas BOUGUES
[email-masked]
Sysop of magix : ++ 33 (1) 45 21 02 52 (shell & uucp)

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

From: [email-masked] (Nicolas BOUGUES)
Subject: Re: Power down idle SCSI disks [w/ kernel patches]
Date: 14 Sep 1994 23:23:25 +0200

Christer Weinigel ([email-masked]) a ecrit:
: I recently asked if anybody had written any code for turning off SCSI or 
: IDE drives under linux. Since it seems as if nobody had done it, I
: gave it a shot myself. And here it is, the result of a few nights 
: hacking of the SCSI drivers.

: Hopefully the kernel patches will turn off a drive after a certain amount
: of time, and if I am really lucky, it might even turn it on when some
: program needs it.

: The patch should be applied from the /usr/src/linux/drivers directory, 
: and it patches sd.c, sd.h and sd_ioctl.c to power down idle disks.
: Idling is disabled by default and has to be turned on by an ioctl call.
: I'm quite new to kernel hacking, so if I've made any horrible misstakes
: I would like to hear about them.

I just tried it, and finds it's a very good idea, since my computer is up 24
hours a day, and I am not sleeping far away from it.

It works pretty well with my SCSI drives (Seagate 1gig and Maxtor 340), but
I experience some problems, looking like timeouts, on spin-ups. I think the
thing to do would be to increase the allowed delay for spin-up, or to have
the drive tell the hosts when it is ready (dunno if it is possible).

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Nicolas BOUGUES
[email-masked]
Sysop of magix : ++ 33 (1) 45 21 02 52 (shell & uucp)

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

From: [email-masked] (Mitchum DSouza)
Subject: Re: Warnings with libc 4.5.26.
Date: 26 Sep 1994 12:30:52 GMT

In article <[email-masked]>, [email-masked] (Bill C.
Riemers) writes:
|> >>>>> "Michael" == Michael H Price <[email-masked]> writes:
|> 
|>     Michael> Before I actually install libc-4.5.26, am I supposed to
|>     Michael> get a million warnings while compiling it or should it
|>     Michael> compile quietly?
|> 
|> I don't get a million, but I do get alot.  It is scary to think that
|> the basic library running everything as so much questionable code.

Well all files are compiled with -Wall on, so it actually warns on every
nitty-picky detail. Even if we (H.J) fixed every single warning then once
a new load of source from another author comes out then we will have to fix
the warnings up again. It is not possible to contact all the authors and tell
them to make their code -Wall clean. Usally the warnings are fairly trivial.

|> The problem I always have, is if I compile libc myself, the gcc 
|> '-g' option doesn't work.  However, when I install the precompiled
|> version the '-g' option works fine.  There is probably some key 
|> instruction I'm missing, but what I do is:

Debugging libraries are NOT compiled by default. For this you need to

        make DEBUG=true

|>   make clean;make depend;make 

drop the "make depend" it is too time consuming. Just do

        ./configure; make

with clean sources
 
|> This doesn't install anything (probably because I never compile as
|> root...)  Also, there are no install commands listed in the README
|> file.  So I just manually copy all the files with:

A "make install" will do the job.

|>   su -c 'cp `find . -name lib\*.so.\*` /lib;cp `find . -name lib\*.sa -or
|> -name lib\*.a` /usr/lib;ldconfig -v'
|> 
|> the *.sa *.a files to /usr/lib.  There is probably some file critical
|> to debugging with a different extention that I'm not copying.
|> 

Mitch

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

From: knaff@ngulu (Alain Knaff)
Subject: Re: more floppy problems with 1.1.51
Date: 26 Sep 1994 11:22:41 GMT
Reply-To: [email-masked]

Steve DuChene ([email-masked]) wrote:
>
>        I applied the patch suggested to floppy.c (changing
>        if(filp->f_mode & 2) to if(filp && (filp->f_mode & 2)) and that
 This fix is wrong (it only works for read only mounts), the real fix
should be if(!filp || (filp->f_mode & 2))

 (Andries Brouwer posted the correct fix a few days ago, and
afterwards, I posted the fix again myself. Apparently we had some news
propagation problems from Europe to the US last week)

>        seemed to take care of the kernel dumps I was getting everytime
>        I umounted a floppy. However I had a umount go into uninterruptible
>        sleep yesterday and I am getting the following errors in /var/adm/
>        messages:
>
>Sep 24 07:35:07 jaguar kernel: floppy: timeout
>Sep 24 07:35:07 jaguar kernel: floppy I/O error
>Sep 24 07:35:07 jaguar kernel: dev 024C, sector 2
>Sep 24 07:35:52 jaguar kernel: floppy: unexpected interrupt
>Sep 24 07:35:52 jaguar kernel: VFS: Disk change detected on device 2/28

 I very recently discovered an error in fsync_dev, which might switch
off the floppy interrupt before all requests are actually processed
(these requests then time out). The interrupt of these timed out
requests then shows up at the next mount (floppy: unexpected
interrupt). I made a patch (against pl1.1.51) to fix this problem, it
is on ftp.imag.fr:pub/ZLIBC/floppy/fdp2509b.diff.gz (This patch fixes
some other problems as well, and makes all floppy ioctl's
interruptible.)
 Alternatively, if you don't want to apply the whole patch, you may
also replace the following lines in floppy_release:
                fsync_dev(inode->i_rdev);
by:
                {fsync_dev(inode->i_rdev); lock_fdc(-1); unlock_fdc(); }

(Btw, that's just one line after the other bug :-) )

 Hope this helps,

        Alain

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

From: knaff@ngulu (Alain Knaff)
Subject: Re: [STATUS] Linus Floppy Driver Development
Date: 26 Sep 1994 11:30:29 GMT
Reply-To: [email-masked]

James Harper ([email-masked]) wrote:
[disk insertion detection]
: All 
: that could be heard was a little click (ever heard an amiga :) and there
: would be no need to constantly check the disk drive, once every couple of
: seconds or whatever would be fine. 
 What's the point of checking the disk only every couple of seconds?
If somebody inserts a disk, it's very probable that he wants to use it
RIGHT NOW, and not only a few seconds later. (Even a few seconds' wait
can be pretty disruptive, if for instance you're browsing through all
your disks to find a misplaced file.)
--
 Alain

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

From: [email-masked] (Andi Kleen)
Subject: Re: ** autoconf.h? **
Date: Thu, 22 Sep 1994 13:02:29 GMT

[email-masked] (Michael_Nelson) writes:

>Recently, when attempting to build some applications (one was yamm), I've
>encountered a problem where the application will #include

>        "/usr/src/linux/include/config.h"

>config.h isn't a problem, because it's there, and it gets #included without
>problem.  But config.h has a line in it that #includes "<linux/autoconf.h>",
>and there is no autoconf.h anywhere on my system.

>So far I've been able to get around the problem by commenting the #include
>of that file out of config.h, and the applications seem to build without
>problem... but it makes me uncomfortable when I have to hack system files
>like this...

>Is this #include of autoconf.h an error in config.h, or should I really have
>an autoconf.h?

You did a "make clean" in /usr/src/linux, didn't you? :-)

autoconf.h is generated by "make config" in /usr/src/linux. 

-Andi
-- 
[email-masked]      Nonsense is better than no sense at all.
|Andi Kleen@2:2480/440.12                           -NoMeansNo, 0+2=1
|PGP-Key available.

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

From: [email-masked] (Rob Janssen)
Subject: Re: Try this IPX bridging code ...
Reply-To: [email-masked]
Date: Mon, 26 Sep 1994 07:57:45 GMT

In <[email-masked]> [email-masked] (Steve Kneizys) writes:

>I know Novell has misused the term bridging, so I am not sure if they
>meant bridge or route. But...

A private mail exchange indicated they indeed mean bridging as it is
defined by the industry...

>If somebody wanted to isolate an IPX net/server from the main net
>in terms of packet density but did not want to change the net 
>numbers, well, bridging would be an option!  I may decide to add
>it to my above bridge, as bridging is faster than routing.

When it is on a dedicated piece of hardware, yes.
But when you program a bridge on a general-purpose machine, you have the
problem that the bridge needs to listen to *all* traffic on both nets, and
lookup all the MAC addresses in some table.  Although the actual bridging
operation may be faster, this operation will be a high load on the machine
that does the bridging.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: Try this IPX bridging code ...
Reply-To: [email-masked]
Date: Mon, 26 Sep 1994 07:58:55 GMT

In <[email-masked]> [email-masked] (Jay Ashworth) writes:

>[email-masked] (Rob Janssen) writes:
>>Why do you want bridging when there already is IPX *routing* available
>>in the kernel?

>Hmmmm... _you_ have a Linux Kernel that speaks NetWare?

>You could save lots of people lots of work.  Where is it?

It is in the 1.1.x series of kernels.

I believe you mis-understand that IPX routing is the same as being able
to access a Netware fileserver.  It isn't.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Mitchum DSouza)
Subject: Re: Building shared libs..
Date: 26 Sep 1994 12:41:13 GMT

In article <[email-masked]>, [email-masked] (Pawel Potocki)
writes:
|> Hello,
|> 
|> My goal is to build several shared, dll libraries for Linux such
|> as 3D graphics libraries (vogl, vogle, Ygl, sipp, plplot) and huge
|> NAG fortan library. I read the documantation included with tools-2.16,
|> looked over the examples, looked over other libraries, and actually
|> already compiled some of the above, but still have some questions,
|> that hopefully someone can answer.
|> 
|> First of all, how do I register the load address of the libraries, so there
|> will be no conflict with other people libraries. And how do I get the stop
|> address?

Eric will give you these values so there is no conflict.

|> Say if the start address is 0x72000000 how do I calculate the stop address?
|> Can I do "size libxx.so.x.x.x" and then add the hex size to the start address 
|> and make the stop addres just bit higher then the above sum?
|> 
|> Second, I did libinfo on several stubs in the /usr/lib and observed that the
|> Global Offset Table size and Jump Table size are same for most of them 
|> (0x1000 and 0x4000). Why is that? Doesn't the size of the library play
|> any role here?

The GOT is just for exported data which generally is quite small for a library
interface who should provide programatic interface to access these anyway, and
the PLT is just a set of pointers into the .text. So no neither of these should 
be large. For some reason everyone kept to the example in the README and
used the same options (0x1000 and 0x4000).

Instead of tearing your hair out and if you are not in any hurry to do the above 
then I strongly suggest you wait, at the most a couple of months, till ELF is
ready for public consumption. This way all the brain work (like figuring out
load addesses and GOT/PLT sizes) will be done automatically by the ELF dynamic
linker ld-linux.so.

Mitch

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

From: [email-masked] (Mike Castle)
Subject: Re: [?] DIP with auto-redial?
Date: Mon, 26 Sep 1994 13:55:41 GMT

In article <[email-masked]>,
John Voth <[email-masked]> wrote:
>Greetings Linux Community:
>
>I am in search of a DIP or DIP-alike program that has auto redial 
>functions built into it. 
>
>I am in constant competition with others trying to connect to my 
>university and the DIP I have now just flops at a busy signal.

I'm not sure if all versions of DIP did this, but I know the most
recent versions set $errlvl to different values, depending on why
it failed.  I'm not positive where the values for errlvl are
documented, perhaps in one of the sample scripts.

mrc
-- 
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly
  [email-masked]     and be right all the time, or not work at all
   [email-masked]       and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

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

From: [email-masked] (David Wright)
Subject: Re: Is there an encrypted filesystem for Linux?
Date: Mon, 26 Sep 1994 13:05:53 GMT

In article <[email-masked]>,
Alan Cox <[email-masked]> wrote:
>In article <[email-masked]> [email-masked] (David Wright) writes:
>>their children) that are transparently encrypted. That is, the cleartext never
>>hits the disk and can't be read even by root. It also stores the filenames
>
>Not true. It hits memory (and can be read by root) and it may end up in 
>the swap area for an indefinite time. Also beware with CFS of people using
>the rpc.portmap bugs (redirected mount request) and just mounting your
>unencrypted CFS freely.
        Ok, of course it is in memory, and can be scanned for there (by root),
and of course maybe in swap. But this pre-supposes that you have the filesystem
mounted at the time. I really think that root on most systems would have better
things to do than sit around waiting for someone to mount a CFS filesystem
just so they could snoop the contents. I typically mount the filesystems only
when I am adding/retrieving files, and then unmount it when I am through,
so the window is fairly small to begin with. Also, the rpc.portmap bug has
been widely reported, and I would assume that anyone who is security
concious enough to use PGP or the CFS package would know how to fix it.

>CFS is a beginning. You need a lot more to have a secure system.

        Of course. I can't imagine how you can be any safer than having
your own private machine. Once you start doing networking you start adding
in more potential for mischief, and only a security newbie would think that
anything they do on a machine for which they are not the only superuser is
secure from someone else seeing it.

                                                Dave

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

From: [email-masked] (Andre Fachat)
Subject: realtime support planned?
Date: 26 Sep 1994 12:55:03 GMT

Hi there!

Is it planned to do some realtime expansions or features
(guaranteed response time) or so for Linux?

Andre

--
Andre Fachat              mail me!             [email-masked]
For some it is MS-Windows, for others it's the longest batch file on earth...

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

From: [email-masked] (Andrej Gabara)
Subject: Re: Linux on CD
Date: 26 Sep 1994 12:25:47 GMT
Reply-To: [email-masked]

In article [email-masked], [email-masked] (Hans Boehm) writes:
|>Also having done this (with a much slower CDROM drive), I suspect there's
|>another problem.  If you're running a big executable from the CDROM,
|>and the kernel needs to page out some of the text segment, it presumably
|>decides that it's already in a file, and there's no reason to write
|>it to the swap space on your disk.  When it needs it again, it just
|>reads it in again from the CDROM.  Oops.  Instead of 40 msecs or so
|>for two seeks on the disk, this just cost you 200msecs (650 in my case)
|>for a seek on the CDROM.  (This is largely conjecture.  Please correct
|>me if I'm wrong.)
|>
|>I still think this is a reasonable way to run, but probably only if you
|>put commonly used executables on the magnetic disk, or have enough
|>memory that the kernel doesn't need to page AT ALL.  Leaving things
|>like man pages on the CD seems fine.

Don't know much about the sticky bit, but would that be a solution? The
text segment of the program (which resides on CD) would have to stay resident in
the swap area, and hence would be either in RAM or swap partition. So, would it
be possible to write a Linux CD with most used programs to have the static bit
set (such as emacs, xterm, ghostscript,...) and just set up a larger swap 
partition on the hard disk? Problem is you can't chmod or unchmod the sticky
bit of binaries on CD rom, or can you with symbolic links? For example, it would
be great to have a 550MB CDROM, all programs available, and a 64MB swap partition,
and most used programs with sticky bit set... BTW, is the sticky bit still supported
in "modern" UNICES?

Just an idea
-Andrej

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

From: [email-masked] (Mitchum DSouza)
Subject: Re: elf benchmarks (getting closer)
Date: 26 Sep 1994 13:44:01 GMT

In article <[email-masked]>, [email-masked] (Marc Fraioli) writes:
|> In article [email-masked],  [email-masked] (H.J. Lu) writes:
|> >No, that is not a typo. ELF may be faster than a.out. But don't take
|> >the result as is. 1000000 iterations are too small. The "benchmark"
|> >varies a lot for both a.out and ELF. We need a better benchmark for
|> >the ELF/PIC library. Also an ELF login shell makes a big diference.
|> >
|> If ELF is so much easier to develop with, and it requires significant
|> effort to craft a benchmark on which a.out is faster, why bother?  I
|> vote for ELF.

There is absolutely no point in benchmarking except to justify the move 
in our own minds. We *have* to go to ELF, there is no turning back. DLL's
have served us well in the past and it is time to forget the old and get in
with the new. The Extendable feature of ELF makes it extremely attractive
and the only viable alternative for serious applications.

With the new `ld' and Eric's `as' front end we can still carry
on supporting both binary types ad infinitum. The libc sources make it
possible to generate either style of library and it will keep doing so to
support the commercial applications which people have already purchased (e.g
Motif). Any fixes to libc will thus affect both DLL's and ELF libraries.

Mitch

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

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

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************