From:     Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
To:       Linux-Development@senator-bedfellow.mit.edu
Reply-To: Linux-Development@senator-bedfellow.mit.edu
Date:     Sat, 13 Nov 93 10:13:20 EST
Subject:  Linux-Development Digest #224

Linux-Development Digest #224, Volume #1         Sat, 13 Nov 93 10:13:20 EST

Contents:
  GCC 2.5.x?  Stability? (Garrett D'Amore)
  Re: Motif - Pay? BAH! (Dragon Slayer)
  Re: Motif - Pay? BAH! (NetDog)
  Re: OS/2 and LINUX INSTALLATION (Daniel L'Hommedieu)
  Re: [Q] Big modem installation for Linux? (Bill Gribble)
  Re: Berkeley Fast Filesystem (jacobsd@heart.cor.epa.gov)
  Motif Project (peter j dohm)
  ioperm for ports > 0x3ff ? (Cedric Adjih)
  Re: Motif - Pay? BAH! (Jaye Mathisen)
  Where is OI (Fredrick Gonsalves)
  Re: Where is OI (Kwun Han)
  Re: Scaner ? (Greg Wettstein)
  Re: STRLEN(<null pointer>) == 3 ??!?? (Robert Sanders)
  Alpha pl13q and serial.c : broken ? (Rene COUGNENC)
  Re: Berkeley Fast Filesystem (Keith Smith)
  Re: 16550A handling in serial.c (Grant Edwards)
  Re: Berkeley Fast Filesystem (Theo de Raadt)
  Re: [Q] Big modem installation for Linux? (Keith Smith)

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

From: garrett@haas.berkeley.edu (Garrett D'Amore)
Subject: GCC 2.5.x?  Stability?
Date: 12 Nov 1993 20:46:04 GMT

Hello Linuxers,

I am curious, has anyone played around much with the newer versions of
GCC 2.5.x (gnu.announce had a post for 2.5.3 on it)?  I've been using
2.4.5 for a while now, and it seems quite stable.  The reason for my 
inquiry is that I am considering building a distribution set that would
expand upon MCC's wonderful release, and I'd like to include and build
my binaries with the most recent **stable** (read usable) version of
GCC, ld, et. al.

I'd like to get a set of opinions, experiences of those who have been
living on the bleeding edge... :^)  I'll post a general summary of
responses if asked.  (If people reply to me via e-mail, that is.  Sort
of pointless to post a summary otherwise... :^)

Thank-you much.

====================================================================
Garrett D'Amore                 |     garrett@haas.berkeley.edu
Software Co-Ordinator           |     68 Barrows Hall, UC Berkeley
Haas Computing Services         |     Ph: 510-643-5923 Fax: 642-4769
====================================================================

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

From: ds2@dragonslair.caltech.edu (Dragon Slayer)
Subject: Re: Motif - Pay? BAH!
Date: 12 Nov 1993 20:29:17 GMT

In article <2bv87oINNpd@junk.cis.ohio-state.edu> dohm@cis.ohio-state.edu (peter j dohm) writes:
>Hi all...
>
>Well, today I wanted to get Mosaic-2.0 and compile it on my machine...
>
>I can't.
>
>Ideally it would be a drop-in replacement for Motif, allowing the end
>user to simply create a soft-link to the "clone" library with a name 
>libXm.a and they would (in a nutshell) have a transparent replacement.
>(you should have a grasp of the idea by now ;)
From what I have seen of the real Motif, it seems similar to Open Look. 
Couldn't a stub/translation type of library be created so Motif stuff
can be translated to Open Look equivalent/similar calls? Also, since 
Linux uses dynamic link, wouldn't this be a matter of creating a library
with the same name and placing it in the appropriate places so a Motif
binary would think Motif is available. This should be easier than creating
reconstructing the Motif calls from scratch. However, this will require 
using Open Look (XView) for any Motif programs, but Open Look is 'free'.

I would be interested in helping, but I don't know X programing to help
coding. 
--
Dragon's Lair, USA
ds2@dragonslair.caltech.edu


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

From: cdent@yod.honors.indiana.edu (NetDog)
Subject: Re: Motif - Pay? BAH!
Date: Fri, 12 Nov 1993 20:24:58 GMT


In article <2c0diq$9ro@pdq.coe.montana.edu>,
Jaye Mathisen <osyjm@cs.montana.edu> wrote:
>
>I am not a Mosaic user, but WTF does the choice of window manager have
>to do with the libraries required to build a program?  
>-- 
> Jaye Mathisen

Mosaic requires the Motif libraries to build. This is tons different
from the choice of window manager. You can run mosaic with whatever
window manager you want.

Chris
--
* Chris Dent | The NetDog | SirReptitious OS(K)N | cdent@indiana.edu * 
* Gophering and Webbing for |  Relativistic Cynicism /// / /  /  /  /*
* the IU Honors Division    |  The Purifying Scourge of the Nineties *

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

From: eagle@garfield.catt.ncsu.edu (Daniel L'Hommedieu)
Subject: Re: OS/2 and LINUX INSTALLATION
Date: Tue, 9 Nov 1993 18:18:09 GMT

stone@panther.cosy.sbg.ac.at (Peter Steiner) writes:
>What I wanted to do is:
>1'st HD: -OS/2-boot-manager in MasterBootRecord + 1MB partition for bootmanager
>               (bootmanager should know about DOS & OS/2 partitions !)
>        -Linux-LILO in DOS-partition partition-loader
>               (LILO should know about Linux- & DOS-partition !)
>        - any DOS , OS/2 or Linux partitions
>2'nd HD: - any DOS , OS/2 or Linux partitions

Maybe I don't understand what you guys want, but here's what I have.  I
have a single IDE drive with four partitions (1 meg boot manager, 165
meg FAT for OS/2 and DOS, 150 meg EXT2, and 16 meg Linux swap).  I
installed Linux its own partition with no problem, then added it to
OS/2's boot manager.  Works with no trouble.  If I want DOS (egad!), I
boot OS/2 and either run a DOS Session, a VDM, or I dual-boot DOS.

Daniel
--
Daniel "eagle" L'Hommedieu / Senior, NCSU CSC Dept / eagle@catt.ncsu.edu

Other stupid UNIX error statements:
rmdir: linux/: Is a directory

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

From: bgribble@jarthur.cs.hmc.edu (Bill Gribble)
Subject: Re: [Q] Big modem installation for Linux?
Date: 12 Nov 1993 22:54:01 GMT

In article <2bu7jrINN1i3@data-hh.hanse.de>,
Christian Kuhtz <chk@data-hh.Hanse.DE> wrote:
>       And I do not think that there are I/O interfaces
>       for PC's who could drive 115KB on 30! lines.

I'd like to see any machine that could control 30! serial lines -- 
let's see.. that's about 2.6525e32 serial lines, according to my calculator,
and at 115kB, that's a maximum throughput of 3.05e36 bytes/sec. 

I think you'll probably need something a little better than a PC..

[ :-) ]

Bill Gribble

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

From: jacobsd@heart.cor.epa.gov
Crossposted-To: comp.os.linux.admin
Subject: Re: Berkeley Fast Filesystem
Date: 12 Nov 1993 23:46:46 GMT

In <WAYNE.93Nov12084551@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt) writes:
>It was my understanding that framents were used only when the entire
>file was 1k or less, but you may be right that it is used for the
>tails of all files.  I am fairly sure that you can't uses multiple
>fragements though, so a 42k file would not be able to use 2
>fragements. 

  I don't think this is right.  Page 199 of "Design and Implementation of
4.3 BSD" says:

     On a filesystem with a block size of 4096 bytes and a fragment size
   of 1024 bytes, a file is represented by zero or more 4096-byte blocks
   of data, possibly plus a single fragmented block.

   ...

   If the file needs to be expanded, the request is rounded up to the next
   fragment size and only that much space is allocated.  Many small write
   requests may expand the file one fragment at a time.  The problem with
   expanding a file one fragment at a time is that data may be copied many
   times as a fragmented block expands to a full block.  Fragmentation
   reallocation can be minimized if the user process writes a full block
   at a time, except for a partial block at the end of the file.

The single fragmented block can contain 2, 4, or 8 fragments.  The file
could be 42k long, but that assumes there is a fragmented block around
with 2k worth of free fragments (or zero so we make a new fragmented
block).  Efficiency suffers, but that's the whole point of fragmented
blocks to begin with -- trade off efficiency of time versus space.  I
don't really like the idea of having to do my own buffering to get the
best performance however.

  This doesn't mean that I agree that BSD FFS is the best to shoot for,
however.  Keep up the discussion -- I'd like to see more filesystem
innovations get tried on the smaller systems (Linux, *BSD) where we can
look at them, instead of only reading someone's paper about their one-
shot implementation.
--
Dana Jacobsen        jacobsd@solar.cor2.epa.gov        Computer Sciences Corp.

"Reading the Bible straight through is at least 70 percent discipline, like
 learning Latin.  But the good parts are, of course, simply amazing.  God is
 an extremely uneven writer, but when He's good, nobody can touch Him."
  -- John Gardner, NYT Book Review, Jan 1983

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

From: dohm@cis.ohio-state.edu (peter j dohm)
Subject: Motif Project
Date: 12 Nov 1993 18:29:42 -0500

Hi again, all..

Well i've been informed by a few people (and now that they mentioned it,
I do remember seeing this in one of the CLARINET newsgroups.. my memory is
going... :) that Motif has been adopted as the user-interface of
choice in the COSE collaboration.  If this is indeed the case, OSF
*supposedly* will release Motif into the public domain for our consumption.

I am contacting OSF currently to determine what kind of time frame they're
planning for this transition.  If it's more than 1.5 years away, maybe I'll
continue with the project making it a drop in replacement + extensions.  If
it's less than a year away, it'd be a great learning experience, but I don't
like to see my sleeplessness (grin)  go entirely to waste...

Just from past experience with these types of things, i'd say it's going to
be a number of months (April, something like that) but not more than a year

hm...

Well, I'll keep you informed as to what I find out from OSF...

Pete
---
+---------------------------------------------------------------------------+
|  Peter J. Dohm - Comp. Science Major    |    The Ohio State University    |
| ** dohm@magnus.acs.ohio-state.edu **    |   ak541@cleveland.freenet.edu   |
| dohm.1@osu.edu, dohm@cis.ohio-state.edu |     dohm@cis.ohio-state.edu     |
+---------------------------------------------------------------------------+


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

From: adjihc4@cti.ecp.fr (Cedric Adjih)
Subject: ioperm for ports > 0x3ff ?
Date: 12 Nov 1993 23:54:57 GMT

* I am trying to run the *.sys for a token-ring card under DOSEMU. The
card uses the ports 0xa20 & 0xa22 (and possibly others...) :

+ 1st Problem: By default the kernel gives only access to the ports 
<= 0x3ff (with ioperm)
+ 2nd Problem: I cannot use "iopl(3)", because when I do so DOSEMU dies.
+ 3rd Problem: When I try to change the IO_BITMAP_SIZE in ioport.c 
or sched.h, which should be the number of ports divided by 32, and 
recompile the kernel, in fact the maximum port I can have access to is 
0x417 (that is "ioperm(0x418); inb(0x418)" gives segmentation fault), even 
for IO_BIPMAP_SIZE = 88 or 128 instead of 32, which should suffice.

Does anyone have a clue ?

advTHANKSance, (and let's put a smiley here, at least :-) ,
--
Cedric Adjih / Internet : adjihc4@cti.ecp.fr
Disclamer : concerning my English.
"Nuclear War can ruin your whole compile." -- Karl Lehenbauer

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

From: osyjm@cs.montana.edu (Jaye Mathisen)
Subject: Re: Motif - Pay? BAH!
Date: 12 Nov 1993 23:38:55 GMT

In article <CDENT.93Nov12152458@yod.honors.indiana.edu>,
NetDog <cdent@yod.honors.indiana.edu> wrote:
>
>In article <2c0diq$9ro@pdq.coe.montana.edu>,
>Jaye Mathisen <osyjm@cs.montana.edu> wrote:
>>
>>I am not a Mosaic user, but WTF does the choice of window manager have
>>to do with the libraries required to build a program?  
>>-- 
>> Jaye Mathisen
>
>Mosaic requires the Motif libraries to build. This is tons different
>from the choice of window manager. You can run mosaic with whatever
>window manager you want.

I think that's what I said.  What has fvwm/twm/gwm/whatever-the-fave-rave-is
have to do with being able to build Mosaic?  Nothing.

So why are people saying the "right" window manager for Mosaic is
fvwm?
-- 
 Jaye Mathisen, COE Systems Manager                (406) 994-4780
 410 Roberts Hall,Dept. of Computer Science
 Montana State University,Bozeman MT 59717      osyjm@cs.montana.edu

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

From: fredg@ariel.cs.yorku.ca (Fredrick Gonsalves)
Subject: Where is OI
Date: Sat, 13 Nov 1993 01:56:09 GMT

I forgot where the FTP site to OI is can someone please E-Mail me the
site

FredG

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

From: kwh@cs.brown.edu (Kwun Han)
Subject: Re: Where is OI
Date: Sat, 13 Nov 1993 03:13:46 GMT

In article <CGEqpL.62u@ariel.cs.yorku.ca> fredg@ariel.cs.yorku.ca (Fredrick Gonsalves) writes:


   I forgot where the FTP site to OI is can someone please E-Mail me the
   site

   FredG

Isn't it in tsx-11.mit.edu:/pub/linux/packages/OI ?

Kwun

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

Date: Thu, 11 Nov 1993 09:25:07 CST
From: Greg Wettstein <NU013809@NDSUVM1.BITNET>
Subject: Re: Scaner ?

>
> Hi Linux-Activists
>
> Has anybody an idea or a driver to make a scaner work under Linux?
> We have a HP ScanJet IIc with an SCSI-interface. Thanks for any help.
>

I am embroiled in the middle of such a project right now.  My current
work is to develop an image processing/storage system for our corporate
Linux network.  I vended a Fujitsu scanner for this project and it is
sitting at home right now, connected to my Linux box there.

The Fujitsu scanner conforms to the SCSI-2 standard for scanners.  I
bought the technical documentation for it and it too is sitting at
home.  I currently have the basics of a driver for it built on top
of 0.99.13.  The driver currently only implements some selected ioctl's
and the basic framework for read etc.  It is not currently capable
of really scanning a document.  Finishing this is on an absolutely
high priority so the next month or so should bring this to fruition.

I would like to donate the driver back to the Linus for inclusion into
the official kernel sources.  I do not know how much appetite there is
for this type of thing but rumor has it that scanners are not well
supported (at least SCSI-2) in the desktop UNIX market.  Perhaps Linux
can be a leader there as well.

I am not sure what type of interface that the HP machine uses.  We
considered vending one of their scanners but the technical support people
were a little bit baucky about giving out interface and programming
details.  We chose the Fujitsu because it was one of the few that
seemed to support SCSI-2.

I will let everyone know when the driver is capable of doing things more
intelligent that it does now.  I would be interested in hearing from
other's who have similar interests or projects in progress.  E-mail
to the address in my .sig is probably preferable to referring to the
e-mail address in the newspost.  This machine is only used for reading
news.

As always,
Dr. G.W. Wettstein           Oncology Research Div. Computing Facility
Roger Maris Cancer Center    UUCP:  uunet!plains!wind!greg
Fargo, ND  58122             INTERNET: greg%wind.UUCP@plains.nodak.edu
Phone: 701-234-2833
======================================================================
`The truest mark of a man's wisdom is his ability to listen to other
 men expound their wisdom.' -- GWW

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

From: gt8134b@prism.gatech.EDU (Robert Sanders)
Subject: Re: STRLEN(<null pointer>) == 3 ??!??
Date: 12 Nov 93 22:21:59 GMT

ftlofaro@unlv.edu (Frank Lofaro) writes:

>>   Under linux,  I took the strlen of a null pointer and was returned 3.
>>
>>Some architecture put a 0 on location 0, some give a SEGMENTATION 
>>VIOLATION, others just don't do special things and give you the
>>data that is availeble on 0.

>It should segfault. That would make trapping NULL pointers easier. It already 
>works for the kernel itself...

And it works for executables, too, since 0.99pl12 or pl13 or something like
that.  You need to compile your programs with the -qmagic flag to a
specially modified ld.  The People In Charge Of This Stuff are waiting
for the newer patchlevels to become more ubiquitous before releasing
tools which produce QMAGIC (0 page unmapped) binaries by default.
This should reduce confusion.

Yes, it does make NULL checking easier.  To be accurate, it makes
NULL through 4095 checking easier.

As an added bonus, QMAGIC binaries are smaller on disk and, because 
the a.out header is contained within the first text page, 4k-page-aligned,
too.  This makes bmap() on the still-unused 4k filesystem easier.

--
 _g,  '96 --->>>>>>>>>>   gt8134b@prism.gatech.edu  <<<<<<<<<---  CompSci  ,g_
W@@@W__        |-\      ^        | disclaimer:  <---> "Bow before ZOD!" __W@@@W
W@@@@**~~~'  ro|-<ert s/_\ nders |   who am I???  ^  from Superman  '~~~**@@@@W
`*MV' hi,ocie! |-/ad! /   \ss!!  | ooga ooga!!    |    II (cool)!         `VW*'

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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: Alpha pl13q and serial.c : broken ?
Date: 13 Nov 1993 02:23:36 GMT


I had a problem when trying the 0.99pl13q kernel, whith the serial port:

It was working fine for sending datas but loosing characters when receiving.
(most of the time people download from my machine, rarely upload, so I
noticed it just tonight, getting a lot af news.. )

Zmodem, or uucp aborting all the time, and a terminal session showing
that many incoming characters were lost.

I just plugged the old "serial.c" from the vanilla pl13, and all these
problems went away... It's late, and a diff shows little difference between
the old and the new module... But there is something strange here.
(Perhaps this is already fixed in another alpha release :-) )

        UART: 16450
        Speed: 38400
        stty crtscts, etc... 
        

BTW, the network seems much slower in this release than in the pl13 from
stock, but more stable (And I prefer that :-) ). And my 3com Etherlink II
does not need a "ping" at boot time any more to start, Thanks to Donald Becker!
Really good job !
--
 linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux 

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

Crossposted-To: comp.os.linux.admin
From: keith@ksmith.com (Keith Smith)
Subject: Re: Berkeley Fast Filesystem
Date: Sat, 13 Nov 93 04:12:08 GMT

In article <2bv87n$724@pdq.coe.montana.edu>,
Nate Williams <nate@bsd.coe.montana.edu> wrote:
>Most of the 'lying' is required because of MS-DOS's 1024 cylinder limit.

Actually,

Most if the lying is due to the use of ZBR and other fancy tricks to
squeeze more data onto the disk.  The IDE's and SCSI's you get do NOT
have a consistant number of sectors on a given track.

Generally speaking there are more sectors on the outside tracks and
fewer on the smaller inside tracks.  Additionally space is reserved for
bad blocks all along the way.

Optimizing code _at the computer_ for disk geometry was an interesing
idea that should now be killed.  One should now leave the low level data
movement optimizations to the DRIVE.  Then a given drive can use it's
cache & knowledge of the drive makeup to optimize on a per drive basis,
probably much more efficiently than you could with the CPU.  The obvious
benifits are simplifying filsystem code to block clustering.
-- 
Keith Smith          keith@ksmith.com              5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...

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

From: grante@hydro.rosemount.com (Grant Edwards)
Subject: Re: 16550A handling in serial.c
Date: Sat, 13 Nov 1993 00:29:49 GMT

Harald Koenig (koenig@ceres.tat.physik.uni-tuebingen.de) wrote:

: I'm using a RS232 line to connect a radio clock receiver which sends
: one character per second at 50 baud. To adjust the UNIX clock as exact as 
: possible it is important to know the exact time of the rising edge of the
: signal (which is detected as start bit). with the current UARTs I only get
: a resolution of 1.25 ms which isn't god enough. 

I don't have any helpful suggestions, but I can't suppress my
curiosity...

Why isn't 1.25 ms good enough?

Is the radio clock reciever that accurate?

Are you writing a device driver to do this inside the serial port
interrupt routine?

--
Grant Edwards                                 |Yow!  I have a very good
Rosemount Inc.                                |DENTAL PLAN.  Thank you.
                                              |
grante@rosemount.com                          |

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

From: deraadt@fsa.ca (Theo de Raadt)
Crossposted-To: comp.os.linux.admin
Subject: Re: Berkeley Fast Filesystem
Date: 12 Nov 93 21:12:12

In article <1993Nov13.041208.1947@ksmith.com> keith@ksmith.com (Keith Smith) writes:
   Generally speaking there are more sectors on the outside tracks and
   fewer on the smaller inside tracks.  Additionally space is reserved for
   bad blocks all along the way.

   Optimizing code _at the computer_ for disk geometry was an interesing
   idea that should now be killed.  One should now leave the low level data
   movement optimizations to the DRIVE.

There are still drives with which this optimization is beneficial.

A good idea is to leave the geometry sensitive code intact, but
only use it if the geometry is known (ie. # of sectors/tracks/heads).
If the geometry is not known, then the disk is just a sequence of
blocks.

For what it's worth, I run with ESDI drives and think the geometry
sensitive code helps performance and placement.

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

From: keith@ksmith.com (Keith Smith)
Subject: Re: [Q] Big modem installation for Linux?
Date: Sat, 13 Nov 93 04:22:45 GMT

In article <2btmvp$qnu@tymix.tymnet.com>,
Wayne Flagg <wflagg@cabernet.tymnet.com> wrote:

[...]

>floppy as I remember.  We used 'em to avoid trying to put >256 ports on 
>a VME box - which was about as attractive as 30-50 serial ports on a 
>linux box. Probably cheaper than buying a terminal server - anyone know 

I run 64 ports on a Digi C/X under SCO with like _no_ problemo. 
Generally have around 35 users logged in at any one time, with a couple
pumping data out to High Speed printers (1400LPM).  All you need is a
smart serial card & drivers.  Someone is/was working on Digi drivers for
Linux a while back.

-- 
Keith Smith          keith@ksmith.com              5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...

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


** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

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

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

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