Subject: Linux-Development Digest #209
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Fri, 23 Sep 94 04:13:14 EDT

Linux-Development Digest #209, Volume #2         Fri, 23 Sep 94 04:13:14 EDT

Contents:
  Re: Any Linux MOTIF packages out there? (Piotr Kapiszewski)
  Re: [STATUS] Linus Floppy Driver Development (Larry Doolittle)
  Re: Shared Libs: working toward a permanent solution? (Craig Milo Rogers)
  Re: 680x0: separate newsgroup? (Michael Neuffer)
  Re: ELF-based Linux distribution? [Was: Shared Libs: working toward a permanent solution?] (David Miller)
  Re: Alpha Linux (Jay Ashworth)
  Re: 1.1.51 seg fault on shutdown in _floppy_release ("Noah L. Gibbs")
  Re: InfoMagic development cd (Jay Ashworth)
  Re: [STATUS] Linus Floppy Driver Development (Daniel Garcia)
  Re: Don't use Linux?! (Darin Johnson)
  Re: Cant mount /dev/mitsumi_cd with kernel 1.1.45 (Aapo Meili)
  NIT for Linux (Timothy E. Onders)
  Re: Extending the IP Protocol? (Sam Oscar Lantinga)
  Does Quicken work under DOSEMU? (Justin Edmond Zaglio)
  Re: Shared Libs: working toward a permanent solution? (NightHawk)
  Re: AX25 & KISS Amateur Radio Protocols in Linux?? (Donald Jeff Dionne)

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

From: [email-masked] (Piotr Kapiszewski)
Subject: Re: Any Linux MOTIF packages out there?
Date: Tue, 20 Sep 1994 18:31:15 GMT

D. Blake Werts ([email-masked]) wrote:

: Just wondering if anyone could direct me to any Linux MOTIF packages out
: there....
I think there is something out there.  Try talking to a friend of mine who
actually mentioned it to me.

        [email-masked] or [email-masked]

-Kapi

-- 
Kapi, 542 Baldy Hall, 645-2448

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

From: [email-masked] (Larry Doolittle)
Subject: Re: [STATUS] Linus Floppy Driver Development
Reply-To: [email-masked]
Date: Thu, 22 Sep 1994 12:56:57 GMT

David Holland ([email-masked]) wrote:
: [email-masked]'s message of 13 Sep 1994 12:27:36 +0200 said:

:  > Generally, I think it's not reasonable to force the user to start some sort
:  > of floppy recognition program after inserting a disk and before tar-xfv'ing
                                          You mean tar -xvf'ing  :-) ^^^^^^^
:  > off /dev/fd0, if the format in question is known to the driver anyway.

: I additionally think it's not reasonable to force the user to look up
: the filesystem type and issue a mount command before reading from the
: disk. Floppies should mount themselves (like on Macs and Amigas) to
: the greatest extent possible given the hardware.

: This is not bloat, it's an important issue for some people.

OK, it's an issue.  But it's bloat if it goes in the Kernel.
This situation cries out for a Kernel hook, and the ability
to have a floppy_mount_daemon that gets activated when the
user puts in a floppy (periodic disk-change check?).  This
program could be a shell script, for all I care, that does
some magic with "file" or some other tools, connects with
some glossy X-based file manager, whatever.  All this is
*not* Kernel functionality, although it may need a Kernel
patch or two to make it viable.

Personally, I would never run such a daemon.  I know people
who would, though.  Any volunteers to write such a beast?

      - Larry Doolittle    [email-masked]

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

From: [email-masked] (Craig Milo Rogers)
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 22 Sep 1994 12:53:05 -0700

In article <[email-masked]> [email-masked] (Michael O'Reilly) writes:
>Richard Krehbiel ([email-masked]) wrote:
>
>: Why is everyone hung up on PIC for shared libraries?
>
>: Why not this way: Take a fairly large chunk of process virtual address
>: space, say 64M or so, and reserve it for shared library code and data.
>: When a shared library is loaded, find an available spot in that range,
>: load it, and then fix up self-relative code and data references with
>: the library's relocation dictionary.  This way you don't pay the
>: performance penalty of PIC, and you still avoid library load address
>: conflicts.  You have to worry about whether all libraries loaded by
>: all processes will fit into 64M, of course, and someone will have to
>: write a relocating loader.
>
>The problem is 'sharing'. When you load the library, you write all
>over it, so you lose badly in terms of shared the library pages
>between processes.

        Richard's proposal is to use the same library-to-address
mapping for all processes, as in the current shared libraries, but to
dynamically allocate the address offset during runtime loading.  Once
a library has been loaded, its address would be fixed (for all
processes in the system) until it is unused and unloaded (if unloading
is implemented).  After the loader fixups are complete, a library's
code pages would be unchanging and would, in fact, be sharable between
processes.

        One downside to this approach is that the library pages,
although shared, are initially "dirty", and must be paged to swap
space rather than discarded and refreshed from the filesystem copy.
Other possible problems are the runtime expense of the relocating
loader, and the disk space needed for the relocation information.  If
you can afford the swap space, these are not necessarily bad tradeoffs
with proper tuning.

        Tuning is the critical issue.  If you have plenty of swap
space and library address space, you want the leave relocated, loaded
libraries lying around in swap even when they aren't being used.  If
you are low on swap space, or library address space, you might want to
use "oldest" or "largest" or some metric combining these to select the
library to evict.  You might want to have a system startup program
preload a list of libraries to improve hater performance.

                                        Craig Milo Rogers

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

From: [email-masked] (Michael Neuffer)
Subject: Re: 680x0: separate newsgroup?
Date: 20 Sep 1994 17:51:09 GMT

Hamish Macdonald ([email-masked]) wrote:

: I'd suggest that people interested in a general Linux/68k port *not* use
: this newsgroup, since it is not a global one.

It is global and connects Fidonet, Mausnet (where the main Atari devellopers 
are) and Usenet.....

Mike 

--
Maus-/UseNet:[email-masked]
Usenet      :[email-masked]
Fido        :Michael Neuffer@2:245/5530.5

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

From: [email-masked] (David Miller)
Subject: Re: ELF-based Linux distribution? [Was: Shared Libs: working toward a permanent solution?]
Date: 22 Sep 1994 20:04:02 -0400

Dan Connolly ([email-masked]) wrote:
: In article <[email-masked]> [email-masked] (Eric Youngdale) writes:

: How many major apps have been built/tested with the ELF tools?

:       * Has the X386 team started messing with ELF tools?
:               (how do they build shared libs for other BSD-based
:               x86 unices like BSD386, NetBSD, FreeBSD, and the like?)

        They are busy as hell as it is... I have a few friends who are
eager to give it a shot once xfree86-3.1 is released. This can wait
though, and we can iron out the major problems before those guys
attack such a task.

:       * I heard emacs excercised some problems with the ELF tools.
:               Anyone care to elaborate?

        Yes, I don't know how many people know what emacs does when it
gets built. First, a binary called 'temacs' gets compiled, all this is
is Lisp interpreter + I/O routines, no editing whatsoever. This gets
executed with a bunch or lisp libraries to load, once the editing code
is loaded, it dumps its core image into an executable. This is asking
for trouble when dealing with alpha/beta shared libs and compilation
tools. Me and eric got one to execute by hacking on the elf-dynamic
loader, so we at least know why it was failing at first.
        Just yesterday I gave it a try with 4.6.9 and 4.6.10, of
course since 4.6.9 did not have termcap, etc., it would not link at
all. Now temacs links but segfaults after loading a few libs then
libc.so, it does crazy system calls for some reason, I am
investigating whether the linker is getting passed bad arguements or
the wrong object files.
        To complicate matters, the existing code in the emacs source
tree which knows how to dump emacs uses mmap() with PROT_WRITE +
MAP_PROTECT which is a lose under linux, I had to use MAP_PRIVATE and
do a HUGE ugly write() right before the mapper file descriptor gets
closed. It works, but hopefully when elf has matured a bit, the mmap
facilities will be in the kernel.

Summary: Emacs can be built, it's been done, but we need to tune
things.

Later,
David S. Miller
[email-masked]

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

From: [email-masked] (Jay Ashworth)
Subject: Re: Alpha Linux
Date: 22 Sep 1994 22:33:52 -0400

[email-masked] (Andrew Bulhak) writes:
>: Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
>: that they do not repeat the OSF/1 idiocy of having only 32-bit ints.

A posting in cola about a week ago said that it would be a 32-bit os, with
access to long-longs.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                       Ashworth
Designer              High Technology Systems Consulting          & Associates
ka1fjx/4                                                
[email-masked]      Linux: The Choice of a GNU Generation     +1 813 790 7592

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

From: "Noah L. Gibbs" <[email-masked]>
Subject: Re: 1.1.51 seg fault on shutdown in _floppy_release
Date: Thu, 22 Sep 1994 11:20:04 -0400

Excerpts from netnews.comp.os.linux.development: 22-Sep-94 Re: 1.1.51
seg fault on shu.. by Barry Yip [email-masked]. 
> >: ::Vincent Fatica ([email-masked]) wrote:
> >: ::: According to zSystem, the error occurs in _floppy_release.
>  
> >: ::: It also occurs on dismounting /b (an ext2 floppy). Thereafter,
mount sa
> ys
> >: ::: it's still mounted (which it's not).
>  
> >: ::Got a similar error with a 'umount -t msdos /dev/fd0 ', but I could not
> >: ::reproduce it.  All I did was try and use pico on files from my 3C579
> >: ::driver disk from 3Com...nothing fancy :)
>  
> >: :True, it happens here as well (1.1.51), but only one time after a
reboot..
> .
> >: :(I did only a mount, ls, umount and it faulted in _floppy_release)
>  
> >: I got the same error yesterday evening. The routine floppy_release
> >: is called by the umount code with NULL as second argument (filp)
> >: and dereferences that. I posted a fix yesterday evening on the Kernel
> >: channel (something like: if(!filp || (filp->f_mode & 2)) ...).
>  
> >If you look in your /var/adm/kernlog, you'll see a nice "OOPS" there
> >also, the code is referenceing a kernel NULL pointer :-) Thank god for
> >qmagic!
>  
> Here running 1.1.51, when I mount a minix floppy and umount it, some
> times I got:
>  
> Oops: 0000
> EIP:    0010:0016a900
> EFLAGS: 00010246
> eax: 00160000   ebx: 00000000   ecx: 00000000   edx: 00160000
> esi: 0006fed4   edi: 0006fed4   ebp: 00000000   esp: 0006fea8
> ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 0018
> Process umount (pid: 1318, process nr: 27, stackpage=0006f000)
> Stack: 001b0200 001b0002 00126193 0006fed4 00000000
> Code: f6 01 02 74 0d 0f b7 46 10 50 e8 ed 76 fb ff 83 c4 04 be 58
> Segmentation fault

   Although I don't mount minix floppies, I have received a nearly identical
'oops' error followed by a Seg Fault and a full crash of the system using
kernel 1.1.45.  Although this involved moving the /etc directory around, and
I was asking for it, I got the error after immediately attempting to reboot
using the 'reboot' command.  I don't know if this is significant, or whether
the error is one common to all lower kernels, but I hope this helps.

                                                Noah Gibbs

(There's a brave new world out there...  Ev'rybody hide)

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

From: [email-masked] (Jay Ashworth)
Subject: Re: InfoMagic development cd
Date: 20 Sep 1994 01:53:30 -0400

[email-masked] (David A. Vohwinkel) writes:
>Does anyone know what happened to InfoMagic ?? I have been trying to get
>in contact with them about their Linux distribution with no luck...

Yup.

They work from home...

..and home moved to New Mexico.

>I called 1-800-800-6613 it has been disconected...

Nope.  It rings down on their Jersey number, and _that_ was disconnected.
The telco dropped the ball, but the 800# should be fixed this week.

>and send email to [email-masked] that have been undeliverable...

Hmmm... maybe it's just that their machine is off line too?  :-)

>all this info came from the Distribution-HOWTO...

Stipulated, there should have been more warning.  But for $20, whadda'ya
want?  Rubber Bis-cuit?

>Does anyone know anything?

Yup.

>       Thanks

You're welcome.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                       Ashworth
Designer                                                          & Associates
ka1fjx/4              High Technology Systems Consulting
[email-masked]                                                +1 813 790 7592

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

From: [email-masked] (Daniel Garcia)
Subject: Re: [STATUS] Linus Floppy Driver Development
Date: 23 Sep 1994 02:56:07 GMT
Reply-To: [email-masked]

Slaving away in a dark room, [email-masked] (Pyramids-R-Us) produced:
>Aonther problem is that there is no simple way to mount a floppy.
>The big question is 'where?'  since a floppy can be mounted on ANY
>directory.  Also I don't want my unprivelged users to be able to mount

What if they did something like on the sgi's, where you can specify 
a mount point for dos disks, and run a daemon that will mount the floppy
automagically (at least, for a dos disk).  Pretty neat though.  Perhaps
if we had something like that for msdos disks only, all others needing
to be mounted manually (therefore, by root)?

D

-- 
 Daniel Garcia - kender@[eri.erinet.com|esu.edu] - Soon to be PhD Student.
UseLinuxReadMoreThinkALotFightClipperBelieveWritePlayMusicOpenHeartsLiveBreath
LoveThinkFeelListenActReasonWatchLearnRideFlySpeakWinFightRiseSingShoutCryDie
<A HREF=http://www.esu.edu/~kender">My Homepage</A> 

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

From: [email-masked] (Darin Johnson)
Subject: Re: Don't use Linux?!
Date: 20 Sep 1994 18:48:10 GMT

In article <[email-masked]> [email-masked] (Shannon Hendrix) writes:

> >Not at all.  Actually, a software company need only create POSIX conforming
> >source code and it will be easily ported to Linux and most other UNIX
> >workstations.  A company should not write software for a specific platform,
> >although writing for DOS or OS/2 probably precludes any portability.

Except that even this doesn't solve everything.  Even places with good
portable code restrict what machines they actually port to (and thus
maintain, purchase machines for, test on, maintain distributions for,
etc).  What counts is actual users or expected users.  It certainly
helps to have POSIX though once the boss says to support a new
machine.
--
Darin Johnson
[email-masked]
    The full name of the compiler is "Compiler Language With No Pronounceable
    Acronym", which is, for obvious reasons, abbreviated "INTERCAL".

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

From: [email-masked] (Aapo Meili)
Subject: Re: Cant mount /dev/mitsumi_cd with kernel 1.1.45
Date: 22 Sep 1994 09:46:32 GMT
Reply-To: [email-masked]

Bob Ashmore ([email-masked]) wrote:
: I have a Gateway 2000 4DX2 66V with a mitsumi cd
: which works OK with Kernel 1.1.0 but when I installed 
: kernel 1.1.45 it will not mount. It gives the error on 
: boot;
: /dev/mitsumi_cd is not a valid block device.
: and if I try to mount it manually it gives the error;
: /dev/mitsumi_cd no such device or address.
: All is OK if I go back to Kernel 1.1.0.
: Has anybody any Ideas 
: PS I did say yes to mitsumi when running make config!

: Bob Ashmore.

I have the same problem.
When booting the mitsumi is recognized but not mounted.
With 1.1 kernel everything went fine.
Interupt and address are set well.

   Aapo Meili

===============================+================================================
                               |    Tel:      +41-1-465 3522
   Alcatel STR AG              |    Fax:      +41-1-465 3525
   Aapo Meili (3.364)          |    X.400:    C=ch ADMD=arcom PRMD=alcatel
   Friesenbergstr. 75          |              S=meili G=aapo
   CH 8055 Zurich              |    X.25:     0228-4795123920::A_MEILI
                               |    InterNet: [email-masked]
===============================+================================================

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

From: [email-masked] (Timothy E. Onders)
Subject: NIT for Linux
Date: Tue, 20 Sep 1994 07:14:40 GMT

Is anyone out there working on the Berkely Network Interface Tap for
Linux?  If so, I'm interested in helping.  If not, I'm interested in
attempting it.
                                        Tim Onders
                                        [email-masked]

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

From: [email-masked] (Sam Oscar Lantinga)
Crossposted-To: comp.protocols.tcp-ip
Subject: Re: Extending the IP Protocol?
Date: 20 Sep 1994 18:43:26 GMT

Gert Doering ([email-masked]) wrote:

: Why not simply using Proxy ARP on the SLIP server? Sounds a lot easier +
: faster.

        Two reasons.  

1)      The SLIP server is on a different subnet.
2)      I don't have access to the SLIP server.

Thanks,

        -Sam

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

From: [email-masked] (Justin Edmond Zaglio)
Subject: Does Quicken work under DOSEMU?
Date: 21 Sep 1994 15:06:22 GMT

The title pretty much says it all: doe any of the DOS flavors of
Quicken work under DOSEMU?  If not, are there any financial packages
that *do* work under it?

Thanks.

--Justin

*****************************  --Das, was man sich vorstellt,
******* Justin Zaglio *******   braucht man nie zu verlieren.
***** [email-masked] *****
***************************** 

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

From: [email-masked] (NightHawk)
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 20 Sep 1994 00:07:59 -0400

Albert D. Cahalan ([email-masked]) wrote:
: In article <[email-masked]> [email-masked] (Eric Youngdale) writes:
:    >Here are a few points to consider and debate:
:    >  o  PIC (position independent code) on x86 processors is
:    >     significantly slower than normal code.

:          The worst I have seen so far is about 3.5% slower for a test of qsort
:    sorting a bunch of integers.

: [---chop---]

:          The suggestion has been made that we somehow come up with a 
:    scheme of using the old libraries (or at least a non-PIC scheme) for
:    common libraries like libc or libX*.  In theory this may be possible, but
:    I would like to get all of the bugs/problems/implementation details shaken
:    out for the PIC stuff, and then we can worry about the possibility of non-PIC
:    ELF shared libraries.  Also, I would like to see some benchmarks that 
:    demonstrate that a performance hit of more than 3% before I get 
:    all excited about trying to implement something like this.

: Every bit counts.  3% here, 2% there, 7% somewhere else - it adds up.
: Actually, it multiplies up, which is worse.
: --

I have been timing the times needed to bootstrap the gcc as well as
compile my kernel. We will know what kind of impacts ELF/PIC on the
speeds of gcc, which I think is a good indicator. It is very slow
on my 486. I hope I can get a Pentium and a big disk by the end of the year. 

NH

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

From: [email-masked] (Donald Jeff Dionne)
Subject: Re: AX25 & KISS Amateur Radio Protocols in Linux??
Date: 20 Sep 1994 07:49:58 GMT

Vassili Leonov ([email-masked]) wrote:
: Rob Janssen ([email-masked]) wrote:
: : >newsgroups for example, just nasty users elsewhere... But every true
: : >hacker might find a lot of use in the HAM radio though I believe....
: : >Vassili.

: : The above is a complete misrepresentation of Amateur Radio, at least as
: : it is regulated in this part of the world (Netherlands, Europe).
: I don't think that the above is a mispresentation - simply I have an
: opinion that is different from yours... still this deosn't automatically
: mean that it's wrong...

Oh, yes, I'm afraid it most certainly does.  The purpose and use of Amateur
Radio is _WELL_ defined in the license the government issues.

: : Amateur radio is a way for individuals to experiment with radio transmissions,
: : mainly for self-education and research.  The exchange of information is

Right.  

: The main accent in self-education and research is in the field of
: computing. The radio itself is rather obsolete and is not of much intrest
: and value these days...

Might I suggest that you be careful about you traffic on the air, your  
attitude is not appropriate for radio.  Just for all that are following 
this thread, our friend here is incorrect.  Radio is the main focus  
(hence the name Amateur Radio).  Digital modes, or packet radio, is
just one of many that we are allowed to use as licensed HAMs.  Packet
is in fact not what those who are not familiar with it would expect...
the fastest connection with -afordable- equipment is 19.2kBps...  You 
quickly find out that you're *NOT* going to FTP the latest kernel source
over packet radio :-)

: : This is not at all related to "the right for free exchange of information".
: : For that purpose, there is CB radio.  In that area there are no limitations
: Can you build a high speed data network wusing CB? Sure you can't...

Oh come on!  Who gave you your license?  There is no real technical diference
between the two that warrents that statement.  Did you not know that
there is an internet class a address space set aside for packet radio on
CB?  27.0.0.0.  Just like the one for amateur radio, 44.0.0.0.  As a 
matter of fact, having written the test to obtain your license, you should
also know that there is a large chunk of space in the 900MHz band that's
now being used for those wavelan ethernet boards, cordless phones... that's
a CB band.  No high speed data links on CB, hogwash.

: : Ever since the inception of "packet radio" there have been greedy looks
: : from the "networking" people on the amateur radio spectrum.  They see it
: : as a way to carry their traffic without having to pay excessive fees
: : to communications providers.
: Yes! It would be GREAT and would benefit the whole human race, if the
: thing like Internet can be trully free and available to individuals and
: "without having to pay excessive fees" - I think it would be very
: much along the lines under which the HAM radio was founded. It's just
: that there were NO computer networks these days....

Amateur Radio was never designed for this purpose.  It's not now and 
never will be the internet of the future.  It's for radio experimentation,
not utilitarian use by the general public.  That's what the telephone 
company and the internet is for.  And....if you want that kind of support,
and to carry that kind of comercial traffic, you have to pay.  All those
things are strictly disallowed on Amateur Radio, which is as it should be.

: : Amateur radio is not intended for this purpose, and by allowing such
: : use of the spectrum the original identity of amateur radio is lost.  Then
: The original identity of the HAM radio is to be at the frontier and
: benefit the humanity - and free of charge... It's public service -
: running a NON-COMMERCIAL network on top of that is no contradiction.

Internet material is VERY commercial, at least in the context of this 
discussion.  Sure, Linux is free, and that's cool.  It's WAY to big
to send over packet (by orders of magnitude), but hey.  Now, I try to
go get it off ftp.cdrom.com and the banner tells me that they have a 
new product for sale.  Since I originated the connection, I'm (technically)
in violation of my radio license.

: : it will be ever more difficult to keep the parts of the spectrum that
: : the commercial communications providers are interested in, because they
: : can easily point at this "unfair competition".
: Competition should serve the humanity - not vice verse. Competition
: is just a vehicle - not an aim in itself. In my opinion - commericial
: providers have unfair advantage of being able to use a spectrum - to
: no benefit of mine... If you look at HAM radio you'll see that it's
: not a technical problem to implement a high speed backbone for a packet
: network, will not take any existing spectrum (how much is spectrum
: above 1GHZ used really - if there is almost no commercial HAM equipement
: on the market for higher then 1.2 GHZ)

Well, there you go.  Another guy that buys equiptment "on the market".
You've missed the point.  Pick up a soldering iron.

: : So, the limitations on information exchange via amateur radio are a good
: : thing.  Don't view them as censorship, but as the regulations that make
: : amateur radio a possibility.

Right. But seriously, if you did'nt like the terms of your license, or
did'nt understand them, you should not have bothered with it in the first
place.  Perhaps you would be better off with a comercial radio license.

: Something - "let's thatnk the autorities and big companies that
: they let us mice exist" approach. I don't like this. 
Is'nt that too bad :-(

: Internet should be
: free and should be based on the free backbones. HAM radio spectrum is
(not fast enough, supported enough, large enough, used for
too many other things,  nd nd or generally not )

: good for that. Don't use it for commericial purposes - but Linux is
: a free projet anyway. The main idea is that free software combined
: with a free backbone can really change the world. Sure there are
: always opponets to these kind of things...

: Vassili.

What's you callsign Vassili?

73! de Jeff / VE3DJF
[email-masked]
[email-masked]
VE3DJF@VE3RPI.#SCON.ON.CAN.NOAM

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

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