Subject: Linux-Development Digest #205
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 22 Sep 94 09:13:14 EDT

Linux-Development Digest #205, Volume #2         Thu, 22 Sep 94 09:13:14 EDT

Contents:
  Re: [STATUS] Linus Floppy Driver Development (David Holland)
  ** autoconf.h? ** (Michael_Nelson)
  Re: Kernel Goals? (Jeff Kesselman)
  Re: HELP NEEDED : device driver (Jeff Kesselman)
  Re: 1.1.51 seg fault on shutdown in _floppy_release (Steve Kneizys)
  Re: Shared Libs: working toward a permanent solution? (Michael O'Reilly)
  Re: Looking for a Fax daemon (Gert Doering)
  FlexFax and Linux: config file anyone? (Mike Dowling)
  Problems with svgalib1.11 and Trident 9200CX card (Peter Onion)
  Re: Alpha Linux (Kevin Marcus)
  Re: Digi Intelligent Boards? (Alan Cox)
  Re: Does Quicken work under DOSEMU? (Michael E. Mendis)
  Re: Sequential IO only thing lacking in Linux ... (Larry Doolittle)
  Re: Shared Libs: working toward a permanent solution? (Eric Youngdale)
  Re: Shared Libs: working toward a permanent solution? (Dejan Ilic)
  Re: Porting applications to TERM (Robert Stockmann)

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

Subject: Re: [STATUS] Linus Floppy Driver Development
From: [email-masked] (David Holland)
Date: 17 Sep 94 15:48:58

[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
 > 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.

--
   - David A. Holland          | -- "Do you have a moment?"   -- "Yes.
     [email-masked] | Unfortunately, it's a moment of inertia."

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

From: [email-masked] (Michael_Nelson)
Subject: ** autoconf.h? **
Date: 21 Sep 1994 14:34:51 GMT
Reply-To: [email-masked]

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?

BTW, I am currently running 1.51, which started as a complete 1.45 with the
subsequent patches applied in sequence.

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

From: [email-masked] (Jeff Kesselman)
Subject: Re: Kernel Goals?
Date: Wed, 21 Sep 1994 19:37:55 GMT

To me, this is the single best design goal for new versions of Linux that 
I've heard (i think I posted a pie-in-the-sky suggestion that someone do 
this quite a whiel back.)  Having said this, I have to admit that my 
priorities at this time don't allow me the time to do it :(

Let me add 2 more reasons (which may be obvious) as to why modularity is 
a good thing.

A) Stripping and recompiling the kernel is a pain even for knowledgaeable 
programmers.  It is not feasable for others.  This limits both the Linux 
audience and, as a result, the desirability to third party hardware 
manufacturers of writing Linux drivers.

B) Stability can only be improved by breaking the system down into 
smaller functional units.

Jeff Kesselman

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

From: [email-masked] (Jeff Kesselman)
Subject: Re: HELP NEEDED : device driver
Date: Wed, 21 Sep 1994 19:41:08 GMT

In article <[email-masked]>,
Kamal T.Mian <[email-masked]> wrote:
>hi folks ,
>
>
>I am intersted in writing/porting to LINUX a device driver for an ISDN
>card that plugs into Pentium PC.
>
>
>My problem is that ... I am very new to Linux .. and donot know from 
>where to start ....
>
>How should one start ?
>
>Any documents available for writing a device drivers ?
>
>Any suggestions or ideas will be highly appreciated ....
>
>It is my class project .... and I have 3-4 months to write it.
>
>
>one can also email me at   [email-masked]
>
>
>regards
>
>Mian

Get yourself a copy of the Linux Bible (published by Yygdrasil, for about 
$45.00).  It puts just about all the available linux docs at your finger 
tips, including 'The Kernel Hacker's Guide' which has a large section on 
writing device drivers (I was just reading it last night.)

Alternately, if you want to go searching aroudn the net, thats where all 
the docs in this book came from.  For me the time saved is woth the 
$40.00 I payed for the book.

Jeff Kesselman

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

Subject: Re: 1.1.51 seg fault on shutdown in _floppy_release
From: [email-masked] (Steve Kneizys)
Date: 19 Sep 94 21:12:20 EST

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 says
: it's still mounted (which it's not).

: Vince Fatica

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 :)

Steve...

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

From: [email-masked] (Michael O'Reilly)
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 22 Sep 1994 15:06:39 +0800

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.

Michael.
-- 
Michael O'Reilly @ iiNet Technologies, Internet Service providers.
Voice (09) 307 1183, Fax (09) 307 8414. Email [email-masked]
GCS d? au- a- v* c++ UL++++ L+++ E po--(+) b+++ D++ h* r++ u+
         e+ m+ s+++/--- !n h-- f? g+ w t-- y+ 

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

From: [email-masked] (Gert Doering)
Subject: Re: Looking for a Fax daemon
Date: Thu, 22 Sep 1994 10:15:33 GMT

[email-masked] (Robert J. LeBlanc) writes:

>seemed only to fit FlexFAX and the efax+Qfax combination due to the
>lack of spooling with mgetty+sendfax.

Well, if you phrase it *this way*, it's not correct, mgetty+sendfax *has* a
spooling system, it's just not a *network* spooler (though it can be used
over NFS).

> It should also be noted that
>mgetty+sendfax requires a Class 2 fax-modem, whereas FlexFAX and
>efax+Qfax work with both Class 1 and 2 fax-modems.

... and it should be noted that mgetty+sendfax supports class 2.0
faxmodems (e.g. the USR), which efax doesn't...

gert
-- 
Yield to temptation ... it may not pass your way again!  --  Lazarus Long
                                                            //www.muc.de/~gert
Gert Doering - Munich, Germany                             [email-masked]
fax: +49-89-3243328                         [email-masked]

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

From: [email-masked] (Mike Dowling)
Subject: FlexFax and Linux: config file anyone?
Date: 22 Sep 1994 09:44:31 GMT
Reply-To: [email-masked]

Oh, dear!  I can't say that I wasn't warned!  Getting FlexFax configured is
giving me a headache.  If anyone has a working config file, I would be very
grateful if you could send it to me together with a very brief description of
your modem.

The Problem: 
I have mgetty+sendfax up and running, so I have no hardware problems.  With the
intention of implementing a fax daemon on a workstation for the department, I
first wanted to try it out under Linux.  Since I don't want my Linux machine to
run 24 hours a day, mgetty+sendfax satisfies my Linux needs completely.

Currently FlexFax is capable of ringing the correct number, but it fails to
communicate with the host.  My problems are compounded by having a German
description of my modem in which the page numbers of the index are wildly out,
and by having to think out all possible German translations of the technical
terms, and search for them by paging through the manual.  Manual does even say
what sort of a modem it is, but FlexFax and my dealer together have worked out
that it is a Rockwell 144DP modem manufactured by Yoriko.
--
                        Mike Dowling 
High-tech Germany presses inexorably on towards fulfilling its great dream of
establishing an electronic mini-crawlway before the end of the next century.

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

From: [email-masked] (Peter Onion)
Subject: Problems with svgalib1.11 and Trident 9200CX card
Date: 20 Sep 1994 08:58:52 GMT

Has anybody else tried to use svgalib1.11 with a trident 9200CX card.

I have a 9200CX card and 66DX2.  Kernel 1.1.35.

The svgalib demos (fun,3d, etc seem to work ok), but vgatest (the one 
which asks you to choose a mode) falls over.  The mode I'm interested in 
is 1024*768*256 (and I think that 800*600 failed as well).  The screen 
goes blank, the scan rate changes but no more video...ever.... until a 
hard reset (preceeded by a shutdown -h of course!)  

The XF86_SVGA X driver works fine on the same card. I looked in the 
source for this and it specifically mentions the 9200CX and says that it 
treats it as a 8900CL (I think).  

Are there any later versions of the trident code for the svgalib, or any 
patches or different values to put into tvga8900.regs?

E-mail replies to the above address are prefered (as the local news host 
only keeps mail for a few days and I may be out of the office for the 
rest of the week!)

Thanks in avdance  Peter Onion.

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

From: [email-masked] (Kevin Marcus)
Subject: Re: Alpha Linux
Date: 20 Sep 1994 08:37:49 GMT

In article <[email-masked]>,
Andrew Bulhak <[email-masked]> wrote:
>Bill Hay ([email-masked]) wrote:
>What is "natural"? An Alpha can handle 32-bit quantities just as
>"naturally" as 64-bit quantities, so it all comes down to convenience.
>And dropping one size, thus making it unavailable to programmers, is
>very inconvenient.

Actually, the Alpha suffers significant performance penalties when dealing
with 32 bit vs. 64 bit quantities.  (Yet another reason NT is slow on
the lower end Alpha's).  

-- 
--> Kevin Marcus, Computer Science Dept., University of California, Riverside
    Email: [email-masked].  
.. "Two types of programs do CALL <next instr>; POP <index reg>.  They are
    viruses and a good chunk of DOS programs.  Down with MicroSloth."

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

From: [email-masked] (Alan Cox)
Subject: Re: Digi Intelligent Boards?
Date: Thu, 22 Sep 1994 09:41:50 GMT

In article <[email-masked]> [email-masked] (Michael Dillon) writes:
>> I visited the Digiboard display at Interop this week, and was told by one
>> of the sales reps that Digiboard was getting pressure from SCO not to
>> promote the creation of new drivers for Linux.  In particular, I was
>> asking about thier new ISDN board they had on display.
>I guess we had better all send some email to [email-masked] 
>explaining that we would rather buy their PC/Xe board than the Cyclades
>board, but we NEED Linux device drivers. Once marketing realizes

It would also be nice if someone could substantiate the above rumour. If it
is true and peopel will admit to it then it would appear a formal complaint
can be lodged from various countries with their US embassy about restraint
of trade. In most countries leaning on people not to support a competitors
product is illegal.

Alan
-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  [email-masked]   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

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

From: [email-masked] (Michael E. Mendis)
Subject: Re: Does Quicken work under DOSEMU?
Date: 22 Sep 1994 11:01:51 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?

I haven't tried the beta version .53 but I have using .52 with quicken.
You can get .52 from sunsite.unc.edu or from the home base tsx-11.mit.edu
-mike

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

From: [email-masked] (Larry Doolittle)
Subject: Re: Sequential IO only thing lacking in Linux ...
Reply-To: [email-masked]
Date: Thu, 22 Sep 1994 02:45:04 GMT

Mark Lord ([email-masked]) wrote:

: Commercial unix systems usually include optimized support for a limited
: number of disk devices, and make use of knowledge of the physical 
: characteristics in optimizing system throughput.  

: For example, i/o requests can be reordered on the fly based
: on the known current rotational position of the spindle,
: rather than just waiting for it to come around again..

: Knowledge of the true physical geometry of the disk lends itself
: to further optimizations, such as organizing data by cylinder
: rather than by arbitrary sequential block numbers (close, but not
: the same results).  To do a good job of this requires further knowledge
: of the sector count/location on each track of the disk.. a complex
: task when variable sectors/track are used.

: Varying the locations of sector/block 0 on each track can yield impressive
: throughput figures, by taking into account the head movement/settling times
: from one track/cylinder to the next, such that the next sequential block
: is just appearing under the heads as the seek completes..

: Lots of nice tricks, most of which require greater internal knowledge of
: a restricted subset of available drives.. 

: Linux, (un?)fortunately, likes to provide more generic drive support.

Fortunately, the trend is to put this level of optimization on
the hard disk itself, which *really* knows where it is :-)
All the OS is interacting with on a real-time basis is the 256K or so
sector/track/cylinder/whatever-RAID-trick-they-pull-next cache.
This arrangement _should_ prove highly satisfactory.

    - Larry Doolittle   [email-masked]

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

From: [email-masked] (Eric Youngdale)
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 22 Sep 1994 11:27:19 GMT

In article <[email-masked]>,
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.

        Technically you can do this with ELF.  When you build the 
library, just omit -fPIC from GCC.  The code generated will ultimately be
relatively fast, but the startup time will really suck because PIC code
tends to have far fewer relocations, and they tend to be organized in such
a way that is more suitable for dynamic linking (i.e. reference 
functions/data through .plt/.got).

        The one thing I am not entirely clear about is where the 
performance hit for PIC comes from.  Is it due to the fact that we lose a 
register, or is it because the addressing modes that are used to reference
data through the %ebx register are slower.  (or both, for that matter).
Anyone have any guesses?

        I am not entirely unsympathetic to the complaints about loss of
performance, but to start with I just want to get vanilla ELF working and
stable.  Once we reach this point, then performance enhancements can be
considered (and I do have ideas).  How much trouble I go to depends upon
how bad the problem really is, and this will become evident as time
goes on.  Whatever enhancements I make to improve performance will have
the following properties:

        1) Fixed address is a possibility, but to achieve this the 
transformation will be local, not global.  Thus each user might have
some utility to pre-load a PIC shared library at some fixed address
and reduce the startup overhead.  The addresses chosen would be local
to each system, so there would not be a worldwide list of addresses.

        2) Processing the assembly code is a possibility, but I want
to eliminate all traces of tables of symbols.  The kind of processing
that I am thinking of would be to change things like foo@GOTOFF(%ebx) to
foo@GOTOFF, thereby changing the addressing mode of the instruction.
For a straight PIC library you would lose if you did this, but coupled
with (1) above, it could be a net win.

        3) Hacking gcc is a possibility, I suppose.  If you assumed that
people would tend to use libraries generated in step (1), then you
could eliminate the requirement that %ebx be saved and reserved.  This
would most likely win back all of the performance loss, but it would be
the hardest.

        Again, the above are all just ideas, and I make no promises that
I will attempt to do anything with them.  What gets done depends upon
how bad the performance hit really is.

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

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

From: Dejan Ilic <[email-masked]>
Subject: Re: Shared Libs: working toward a permanent solution?
Date: Thu, 22 Sep 1994 11:11:19 +0200 (MET DST)

On 21 Sep 1994, H.J. Lu wrote:

> Date: 21 SEP 1994 13:51:26 GMT 
> From: H.J. Lu <[email-masked]>
> Newgroups: comp.os.linux.development
> Subject: Re: Shared Libs: working toward a permanent solution? 
> 
> I have released a complete ELF developement kit for testing. Everything
> in it is linked with one or more ELF/PIC libraries. From what I have seen
> so far, the speed of ELF/PIC shared library is pretty good. I hope someone
> will compile an entire Linux distribution with ELF to see how good/bad
> it is. With ELF, you can easily make shared libraries without worrying too
> much :-).
> 
> FYI, the public release of the Linux C library will contain the ELF
> version of the shared libraries.
> 
> H.J.
> 
> 

Very nice, but where do we grab it for testing ?

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

From: [email-masked] (Robert Stockmann)
Subject: Re: Porting applications to TERM
Date: Wed, 21 Sep 1994 16:44:57 GMT

: Porting shouldn't be necessary with the new termnet library. Add in
: the program Makefile following definitions:

: to CFLAGS -include /usr/local/lib/termnet.h  (or whereever)
: to LIBS   -ltermnet -L/usr/local/lib         (     ="=    )

: That should do it. Note that -include is not understood by some C
: compilers (but gcc does grok it :-)

: Ideally, programs compiled in this way run with and without term
: and/or TCP/IP, they always take what's available. 

: Olaf
: -- 
: ___     [email-masked] - [email-masked]
: __ o      <a href="http://rzstud1.rz.uni-karlsruhe.de/~uknf/">click</a>
: __/<_     also: [email-masked] - [email-masked] - praetorius@irc
: _)>(_)_________  "now i find that most of the time love's not enough 
in itself"

I think its amazing! does that mean that also smail/sendmail can be compiled
with term within? how can you than receive email if your term pc is
not registered with a valid hostname?

Robert Stockmann
[email-masked]

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

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