Subject: Linux-Development Digest #153
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 11 Sep 94 01:13:06 EDT

Linux-Development Digest #153, Volume #2         Sun, 11 Sep 94 01:13:06 EDT

Contents:
  Re: Linux Micro-Kernel? (Louis-D. Dubeau)
  Re: Why I cannot mount a PhotoCD on Mitsumi ? (Tamas Badics)
  Re: DOS BC++/Linux floats (Adam DePrince)
  compiling 1.1.46+ ... I went to .50 :) (Steve Kneizys)
  Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders) (Mitch Davis)
  Re: lossage with "tar cz" writing to gzip; easy fix? (Mitch Davis)
  Re: Don't use Linux?! (Jeff Kesselman)
  Re: i Enhanced IDE controller drivers (David Miller)
  1.2.0 - 1.3.0 questions -- Has anyone heard?
  Choosing PLIP/printer w/switchbox w/o reboot, HOW? (Greg Smith)
  Re: Linux console to SCO comp. prob (Doug Ledford)
  Re: Why I cannot mount a PhotoCD on Mitsumi ? (Jeff Kesselman)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Dan Pop)
  Re: Alpha Linux (Joe Zbiciak)
  Re: Alpha Linux (David Holland)
  3c509 Problems (Danek Duvall)
  Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders) (Michael Haardt)

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

From: [email-masked] (Louis-D. Dubeau)
Subject: Re: Linux Micro-Kernel?
Date: Sat, 10 Sep 1994 16:12:07 GMT

>>>>> "iv" == ian vogt <[email-masked]> writes:

    iv> Does Linux use a micro-kernel?

No.

    iv> If not, does it use any mico-kernel-type techniques?

A mico-kernel, is it some kind of mushroom kernel? :-) Seriously, I
don't think so but I may be wrong since I didn't check *all* of the
kernel sources... especially the part dealling with loadable modules
which could use microkernel technologies.

    iv> Is there any plan to make Linux more like a micro-kernel?

No, but there is a plan to *port* it to a mk... Mach in fact. I
haven't posted any announce about it yet but I now have a Hurd
compatible ext2fs server up and running. Some objections come to mind
when I talk of the project of porting Linux to Mach using Hurd as a
development base:

        - Mach 3.0 is slow and big: this will be taken care of in Mach
        4.0 currently developped by Bryan Ford at the University of Utah.

        - Mach is controled by CMU: false. You can modify and
        distribute modified copy of the source code. Moreover, Bryan
        Ford (Mach 4) is open to external criticism/suggestions and is
        a Linuxer anyway.

        - the Hurd is not there yet: true, but it will be here soon.

        - the Hurd is controled by the FSF: false. If at any time the
        Linux community feels that linuxhs (or linurd or whatever the package
        will be called) do not fit their needs, they are free to modify *any*
        part of the sources. Official distributions of the future package
        will not need to have the original unmodified Hurd code in place. Heck,
        that's one of the goals of the GPL.

Take a look at http://step.polymtl.ca/~ldd/ for more info on the
project. BTW, volunteers are welcome.

        ldd

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

From: [email-masked] (Tamas Badics)
Crossposted-To: comp.os.linux.help
Subject: Re: Why I cannot mount a PhotoCD on Mitsumi ?
Date: 10 Sep 1994 21:59:16 -0400

[email-masked] (Jeff Kesselman) writes:

[many interesting technicalities deleted...]

>The poitn of all this is that ALL CD-ROM types are fully ISO9660 
>compatable. (other than perhapse really wierd propritary formats-- I won't 
>even guess what the Atari Jaguar does).

>[email-masked]

OK, it is all nice to know, but how can I read a PhotoCD on a Mitsumi drive?
(My MS-DOS driver can read them without problems.)

Tamas

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

From: [email-masked] (Adam DePrince)
Subject: Re: DOS BC++/Linux floats
Date: Fri, 9 Sep 1994 03:06:30 GMT

[stuff delted]
>>Have you tried using double in DOS? You could be having the same int/long
>>problem you were having with integers. Linux is 32bit and I suspect (!)
>>that it's floats are too. DOS floats are 16bit
>

float = 32 bits [23/8]
double = 64 bits (IEEE standard double)
long double = 80 bits [56/23]

A 16 bit float would offer about as much range and far less precision than
a 32bit fixed point.  

The IA FPU can deal with 32, 64, and 80 bit floats.  Additionaly it 
can handle 32 and 64bit integer math (yes, an 8087 gave me fast 64bit
integer math on my 8088).

The Int/long problem that you are confuseing floating point numbers with 
lies in the lack of explicit definiton of how large a "int" is in C.

"short int" and "long int" are pretty standard, but "int" will be
either 16 bits or 32 bits depending on the mood of the compiler implementor.
-- 
=====================================================================
| Tic.                          | Adam DePrince                      |
|                               | CIS Gradute Student                |
|                               | New Jersey Institute of Technology |

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

From: [email-masked] (Steve Kneizys)
Crossposted-To: comp.os.linux.help,comp.os.linux.admin
Subject: compiling 1.1.46+ ... I went to .50 :)
Date: 8 Sep 94 23:43:21 EST

In article <[email-masked]>, [email-masked] (Dougal Campbell) writes:
> In article <[email-masked]>, Carlos Dominguez said something like:
>> I'm trying to compile the latest/greatest kernel in order to
>> get support for my 1mb/sec QIC80/floppy controller.
> 
>> I got the 1.1.45 kernel, applied all the patches sequentially from
>> 46 to 49 to my 45 source tree, and whenever I do a make dep I always 
>> get this.
> 
>> ksyms.c:13:  linux/blkdev.h: No such file or directory
>> make[1] *** [dep] Error 1
> 
>> I did a diff between a ksyms.c and a ksyms.c.orig and the diffs were
>> that statement and a "BLOCK DEVICE" section towards the end.
> 
>> Can/Should I compile even with this dependency error?
> 
> I ran across the same thing when I compiled the 1.1.49 kernel.  The
> patches seem to not place some of the files correctly. If you look in 
> directory you applied the patches from (probably /usr/src or 
> /usr/src/linux) I'd bet that you'll see some stray .h and .c files.
> Look at what source files the make fails on, look at the paths, and move
> the stray files to their proper directories.
> 

Just did this, except I went to 1.1.50 release.  I started with the 1.1.45
tar file, and did the patches 46 through 50 sequentially from the /usr/src
directory.  Then I moved the .c and .h files (I think they were just
blkdev.h, ncp.h, ni52.h and ni52.c) created in /usr/src to the subdirectory
linux/include/linux, then moved entry.S to /usr/src/linux/kernel directory.
Did the standard makes and it booted on the first try!  Did it by modem
too...brave soul I am :)

Take care!

Steve...
============================================================================
|    Steve Kneizys                            [email-masked]       |
|    Director                                 P.O. Box 1000                |
|    Academic Computing                       Collegeville, PA 19426       |
|                                             Phone (215) 489 4111 x 2244  |
|    Ursinus College                          FAX   (215) 489 0634         |
============================================================================

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

Subject: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders)
From: [email-masked] (Mitch Davis)
Date: Thu, 8 Sep 1994 04:37:34 GMT

In article <[email-masked]>,
Chris Wong <[email-masked]> wrote:
> 
>hd.c: ST-506 interface disk with more than 16 heads detected,
>  probably due to non-standard sector translation.  Giving up.
>  (disk 0; cyl=950, sect=32, head=64)

Hello All:

I have two ST-506 HDs, of about 44 meg each.  They've always worked fine
with Linux, but kernels have never been able to identify them as ST-506.
At boot time, the kernel always says "unknown".

(I have another machine where the IDE drive is correctly identified).

I used to think this was because the ST-506 interface was so old that
no-one was particularly bothered about identifying it.  But from the
quoted message above, it appears _something_ in the kernel knows it's
an ST-506....

Can anyone suggest what the trouble might be?  Would anyone be
interested in remedying this?  Should I start reading hd.c?  I am
happy to do whatever would be required.

Thanks,

Mitch.

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

Subject: Re: lossage with "tar cz" writing to gzip; easy fix?
From: [email-masked] (Mitch Davis)
Date: Thu, 8 Sep 1994 06:38:12 GMT

In article <[email-masked]>,
Chris Metcalf <[email-masked]> wrote:
>Does anyone have a patch to fix the problem with "tar cfz" where if you
>suspend and background the process, it dies with a wrong-size return
>from write()?  I'm surprised to see such behavior in Linux, which is
>pretty well-standardized most of the time.  (Clearly the write to the
>pipe is returning after an atomic-sized write on an interrupt, but
>it would be nice to suppress that behavior.)
>
>This is with tar 1.11.2 and gzip 1.2.4 (and libc 4.5.26 with Linux 1.1.49,
>but it's been going on a long time); a typical error message would be
>"tar: only wrote 2048 of 10240 bytes to foo.tgz".  Email me with any
>responses and I will post a summary.

I thought I was the only person with this problem!  I've also noticed it
when I've had to press ^Z while recompiling the kernel.

Mitch.

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

From: [email-masked] (Jeff Kesselman)
Subject: Re: Don't use Linux?!
Date: Sat, 10 Sep 1994 20:14:18 GMT

Rather then waste bandwidth repeating the previous arguments and 
commenting in response, I'm just going to kame a few overall comments.

1) I do agree that Linux is not for the unwashed to administrate, you 
really DO need to know something about UNIX to make this beastie work, as 
the Docs tend to be somewhat sketchy.  This is particularly true on 
low-end hardware.  If you have fast enough hardware, and are willign to 
pay for standard enough stuff (as opposed to a cheapie patched togetehr 
system like i have) at this point installing PnP from yygdrasil is 
probobly about as easy as installign OS/2 or Windows (which isn't sayign 
much), but admin is trickier.

This is natural however, 'cause this is UNIX folks.  UNIX is very 
powerful, and very streamlined, but the pwoer comes at the price of less 
touchy-feely-hand-holding.  I honestly think this laterst version of 
Linux is as easy to adminster as my old 'professional' SCO.  Remember that
this is a real, mature, multi-user system.  None of the others I 
mentioend above are.

2) Getting commercial developers to develop for linux.
Frankly, at the moment the BEST way to encourage this is to continue to 
give Linux away.  Lets get real, for a minute.  it doesnt matter HOW nice 
your OS is if you can't get a large number of installatiosn installed.  I 
DO work for a professional software firm and our primary concern on new 
platforms is how many customers thre will be for the final product.  If 
we believe there will be enough, we develop for it.  (A great exampel is
the Sega Saturn, which we are developing for rigth now even though its 
develoment environment is putrid!)  We have seen how successful $500.00+ 
UNIX systems have been at penetrating (virtually nada.)  Frankly, I 
STRONGLY suspect more new Linux system have been brought up in the past 
quarter then SCO systems in the past year.

3) Quality of software.
Well, I happen to consider quality not to onyl be the province of large 
shops.  Soem of the most groundbreaking, exciting products have come out 
of garages.  To a certain degree a big company is proscribed in how 
foward looking they can be as they have large marketing/sales structures 
to support.  I think we will start to see very exciting products come out 
of peoples garages for Linux in the next year or so.  

4) the WSYWIG issue
I agree with the original author's point here, I'm afraid.  it doesn 
matter how increidbly powerful TeX is, its stil la form of programming 
and is NOT friendly enough for your average business person to use.
BUT how abotu this-- why doesn't someone write acurses-based WSYWIG that 
generates TeX out the back end?  Sure it wont be as powerful as raw TeX, 
but it will make it accessible for all those who just need light word 
procvessing capabilities.  This is gfthe fundemental spirit of UNIX... 
take whats there and jsut add to it the additional functionality you
need.  (Frankly I think there's ALOT of money to be made in this
product alone.  Without the big-boys tro compete with, there is room for 
a midnight-engineer to really make a splash.  Ild do this one myself, but
I'm running Linux at the moment to experiment with enhanced AI which I
hope to bring abck into our games at work.)

My three cents, for what its worth.

Jeff Kesselman
[email-masked]

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

From: [email-masked] (David Miller)
Subject: Re: i Enhanced IDE controller drivers
Date: 10 Sep 1994 19:38:11 -0400

Steve van Aardt ([email-masked]) wrote:

: Has anyone developed an Enhanced IDE controller for LINUX ?

: I'm intending to run Linux upon a Pentium 90 m/c - has anyone
: found any difficulties with doing so ?

        Just  installed slackware on a Dell Dimension P90, and the
eIDE works beautifully, and its real quick.
        Use kernels 1.1.50 or newer or it won't work no matter what
you try. The newer kernels know to talk directly to the drive for it's
specs instead on relying on BIOS bogus values.

Later,
David S. Miller
[email-masked]

: --
: Steven van Aardt, 
: CS First Boston, One Cabot Square, London. E14 4QJ
: Tel: +44 (0) 71 516 2547

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

From: [email-masked] ()
Subject: 1.2.0 - 1.3.0 questions -- Has anyone heard?
Date: 11 Sep 1994 02:22:36 GMT

Does anyone know if built-in-quota and accounting support is planned for 
the new release?

--Craig A. Huegen

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

From: [email-masked] (Greg Smith)
Subject: Choosing PLIP/printer w/switchbox w/o reboot, HOW?
Date: Sat, 10 Sep 1994 20:36:34 GMT

Hello,

I have two Linux boxes with kernel 1.1.45.  They are (sometimes) 
connected with PLIP and other times I reboot one and use a switchbox on 
the parallel port to print.  I must reboot because it seems the PLIP 
code, once configured in the kernel, interferes with the printer /lp 
code.  Is there a way to switch between my PLIP connection and my printer 
without rebooting? (just ifconfig'ing it "down" doesn't seem to work.)

Greg Smith
[email-masked]

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

From: [email-masked] (Doug Ledford)
Subject: Re: Linux console to SCO comp. prob
Date: 10 Sep 1994 23:52:08 GMT
Reply-To: [email-masked]

On 2 Sep 1994 13:17:14 +0200, Jonathan Noel Tombs ([email-masked]) wrote:

: what is the problem with the linux keymaping. I can generate 16 different
: characters/sequences per key as far as I am aware. linux seems to
: supports all shift/control/alt posabilities. 

: What is it that SCO can do that linux not? Or is it just you haven't
: bothered using loadkeys and the default map defines some sequences as
: the same.

: Jon.

Actually the problem goes something like this.  You can indeed define 16
characters/sequences per key.  However, since the kernel code performs a
string lookup for defined sequences, you have to be able to define the strings
for those keys you wish to send out sequences, such as F-keys, with the 
exceptions of arrow keys and keys on the Keypad.  In Linux, you have a total
of 36 strings available.  Several of these are used on specific keys already,
such as home, end, pgup(Prior), pgdn(Next), and so on.  What you are left
with is 26 F-key strings that are definable.  If you define 16 sequences for
F1, then you only have 10 strings left.  In order to define 4 sequences per
F-key on a 101 key keyboard (12 F-keys), then you need at least 48 strings
available.  Linux doesn't have that many.  Furthermore, to get it is a kernel
change.  I have made this change on my system.  Furthermore, I defined my
4 sequences per F-key the same as SCO console so that WP for Unix would
work.  I redefeined my termcap (actually I left the standard termcap entry
and added SCOconsole) and now my console actually works better for me than
it did.  I created a loadkeys mapping that could be used on any system with
the number of strings in the kernel bumped up and would create a keyboard
the same as SCO, as well as another one to put it back into Linux standard
mode.  In other words, the problem is fixed here, and I can use Linux
default or SCO default.  Furthermore, the Linux software I use was written so
that it reads the termcap entry and as such it works fine either way.  Someone
else would have to test the other Linux software and see if they can find any
that is broken by the change.  I know some people want this, but since the
maintainer of loadkeys is getting ready to put out a patch to the kernel that
is nicer than my own, I'm not planning on uploading it anywhere.  If someone
needs this fix NOW, then mail me with a place to send it and I will.

--
*-----------------------------------------------------------------------*
*  Doug Ledford                        | [email-masked]          *
*  948 E. Normal                       | College of Natural and         *
*  Springfield, MO 65804               |   Applied Sciences             *
*  (417)866-2324                       | Computer Sciences Major        *
*-----------------------------------------------------------------------*

Psychotherapy is the theory that the patient will probably get well
anyhow and is certainly a damn fool.
                -- H. L. Mencken

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

Crossposted-To: comp.os.linux.help
From: [email-masked] (Jeff Kesselman)
Subject: Re: Why I cannot mount a PhotoCD on Mitsumi ?
Date: Sat, 10 Sep 1994 23:38:24 GMT

In article <[email-masked]> [email-masked] (Erik Mouw) writes:
>In article <[email-masked]>, [email-masked] (Tamas Badics) writes:
>> Hi Again,
>> 
>> I asked the above question once, but had no positive answer. 
>> The problem is the following:
>> 
>> I'd like to mount a PhotoCD using Linux 1.0.9 and a Mitsumi doublespeed 
>> CD drive. I guess the "mount -t iso9660 /dev/mcd /cdrom" command should
>> do it, but it doesnt. It gives the usual 
>> "mount: wrong fs type, /dev/mcd already mounted, /cdrom busy, or other error"
>> error message.
>> 
>> Is the PhotoCD compatibility missing from the mcd.c driver? 
>> 
>> I CAN mount regular data CD-s on the same drive with the same command.
>> Also, the same drive CAN read PhotoCD-s under MS-DOS, so it is not a hardware
>> problem.
>> 
>> Anoybody knows the solution to this?
>> 
>> Thanks,
>>      Tamas
>> 
>
>I think the errormessage says enough: photo CD's don't have a 
>ISO 9660 filesystem on it, otherwise Linux should have mounted it.

Good guess, but wrong, I'm afraid.  I was working for Philips at AIM in 
Los Angeles during the development of the original CD-I software.  I 
mention this as a way of establishing my credentials for the following 
information:

CD formats are defiend as a set of specifications, each bulding on the 
top of previous ones, much like a network stack or an inheritance tree.  
They are generally referred to by the color of the cover of the official 
release.  They are as follows:

Red Book: The root standard, defines CD-DA (CD-Digital Audio, what most 
cousumers just call 'CDs'.)

Yellow Book: The ISO9660 standard, defines CD-ROM. A full superset of 
the red Book.

Orange Book: (I believe, I'm a little rusty on the color of thsi one), 
CD-ROMXA (eXtended Architecture.)  This is a full superset of the Yellow 
Book, which adds the cocnept of the 'real-time file'.  Included in RTFs 
are a couple of standard ADPCM interleaved audio types and advanced error 
checking. RTFs are ALWAYS in contiguos sectors (not a requireement of 
Yellow Book files) gauranteeing data delivery with-out seek delays.

Green Book: The CD-I spec. Expands on Orange Book by definign a standard 
host computer attached to the XA drive, and additional data types for 
more ADPCM audio compressions varients and video bitmap types.

Gold Book: Photo-CD. Another full superset of the Yellow Book, with 
specific data types defined for hi-res photos. Also includes CD-I type 
ADPCM audio, as well as a pre-defiend directory structure for finding files.

The poitn of all this is that ALL CD-ROM types are fully ISO9660 
compatable. (other than perhapse really wierd propritary formats-- I won't 
even guess what the Atari Jaguar does).

[email-masked]

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

Crossposted-To: comp.lang.fortran
From: [email-masked] (Dan Pop)
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: Sat, 10 Sep 1994 20:59:34 GMT

In <[email-masked]> [email-masked] (Bill McKinney) writes:

>The problem is that my original code might not compile under f2c/gcc.
>I don't want to spend time "fixing" codes (that have already been working
>and optimized) so they'll run under f2c/gcc and allow me to do development
>on Linux.

Is there any _F77_ code which doesn't work under f2c/gcc?

Dan
--
Dan Pop 
CERN, CN Division
Email: [email-masked]
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

From: [email-masked] (Joe Zbiciak)
Subject: Re: Alpha Linux
Date: 10 Sep 1994 15:57:49 -0500

In <[email-masked]> [email-masked] (Johan Myreen) writes:

>What is the natural word size of the 68000?  Or the 8088?  Or a

Even better:  The 68008...  8 bit data path, 16 bit registers, 32 bit ALU.
By 32 bit ALU, I mean two registers would combine together and make a 32 bit 
register for ADD & SUB and MUL & DIV (I think.) 

--Joe

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

Subject: Re: Alpha Linux
From: [email-masked] (David Holland)
Date: 8 Sep 94 17:09:17

[email-masked]'s message of 06 Sep 1994 16:38:15 GMT said:

 > Why drop one? 
 > 16 bits = short int
 > 32 bits = int
 > 64 bits = long

Over in the next thread people were talking about Unicode; why not

16 bits = char
32 bits = short
64 bits = int, long

Of course that would break a lot of things, but such is the price of
progress :-)

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

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

Crossposted-To: comp.os.linux.help
From: [email-masked] (Danek Duvall)
Subject: 3c509 Problems
Date: Sat, 10 Sep 1994 20:32:17 GMT

I recently set up my 3Com Etherlink III Combo on my linux machine.
The first boot after the network stuff was configured, it worked fine.
In fact, it worked fine continuously for over a day.  Then, today, I
was having some problems compiling and installing sendmail, I rebooted
my machine.  At that point, I couldn't find anything on the network.
I hadn't changed any relevant pieces of the network config files, so
it couldn't have been that.  Then I checked /var/adm/messages, which
had the line:

  eth0: Missed interrupt, status then 2011 now 2011 Tx 00 Rx 383c

The same line appeared every time I booted, exced that the last number
would change.  I found the spot where this gets printk'ed, but I know
nothing more than that.

Please!  If there's anything anyone can do to help, I would really
appreciate it, since I have almost no clue about the networking code
(except what I've read in the NAG and the NET-2-HOWTO).  If there's
any further information you need to figure out what's going on, please
get in touch.  (My kernel version, by the way, is 1.1.49.)

Thank you very much,
Danek

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

From: Michael Haardt <(michael)[email-masked]>
Subject: Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders)
Date: Fri,  9 Sep 94 19:18:11 MET

[email-masked] (Mitch Davis) writes:
> I used to think this was because the ST-506 interface was so old that
> no-one was particularly bothered about identifying it.  But from the
> quoted message above, it appears _something_ in the kernel knows it's
> an ST-506....

Yes, I don't have a clue why it was done that way.  The following patch
fixes it:

        if (unmask_intr[dev])
                sti();
        if (stat & (BUSY_STAT|ERR_STAT))
!               printk ("hd%c: ST506 interface, %dMB, CHS=%d/%d/%d\n",
!                       dev+'a',hd_info[dev].cyl*hd_info[dev].head*hd_info[dev].sect/2048,hd_info[dev].cyl,hd_info[dev].head,hd_info[dev].sect);
        else {
                insw(HD_DATA, (char *)&id, sizeof(id)/2); /* get ID bytes */
                max_mult[dev] = id.max_multsect;

Once I sent this to Linus, but no response.  IDE drives can tell you
their parameters, whereas for ST506 interface drives, you need to
believe the BIOS, which may be incorrent.  Nevertheless, I like to see
the parameters at booting.

Michael
--
Twiggs and root are a wonderful tree (tm) Twiggs & root 1992 :-)

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

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