Subject: Linux-Development Digest #881
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, 2 Jul 94 16:13:12 EDT

Linux-Development Digest #881, Volume #1          Sat, 2 Jul 94 16:13:12 EDT

Contents:
  Re: CD Recorder Driver? (Stefan Markgraf)
  Re: Floppy code broken w. 1.1.23 (Matthias Urlichs)
  Why autoprobing disabled for eth1-eth3? (Igor Sharfmesser)
  Help: Modules in Linux kernel (Janusz Zamecki)
  Re: Floppy code broken w. 1.1.23 (Sverre H. Huseby)
  West. Digi. 540 MB Hard drive--HELP! (Dorwin Shields)
  Re: Quirky idea: Remote Virtual Consoles (James B. MacLean)
  Re: Dosemu & serialport video work? (James B. MacLean)
  Re: CD Recorder Driver? (Randy Chapman)
  Re: atdisk2 patches and 1.1.23 - Help !!!!!!!!!!!!!! (Delman Lee)
  Re: Quirky idea: Remote Virtual Consoles : More Thoughts (James B. MacLean)
  Linux Development Documentation (Ioi Kim Lam)
  Re: ISDN device driver (Martin Sohnius)
  Linux seems to perform terribly for large directories (Luke Kendall)
  PPC mailing list? (Philippe Steindl)

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

Crossposted-To: alt.os.linux,comp.os.linux.misc
From: stefan@pippi.tu-bs.de (Stefan Markgraf)
Subject: Re: CD Recorder Driver?
Date: Fri, 1 Jul 1994 07:57:43 GMT

>I have heard a rumour that there is a Phillips CD-R (recordable CD) driver
>for Linux.  Does anyone know anything about this driver?  Anyone actually
>been able to use the CD-R with linux?
Do you really believe you can convert a CD-ROM into a writable CD?
I think there was a warning that this driver is a virus 
which destroys the harddisk.

Okidoki,
        Stefan.
                         \\|//
                         (^ ^)
======================ooO=(_)=Ooo=======================================
sig: Stefan              {   }          stefan@geophys.nat.tu-bs.de
     Markgraf            {   }          Phone: +49 531 391 5231
                         {   }
=========================U===U==========================================
                        /| | |\
                       ooO   Ooo


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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Floppy code broken w. 1.1.23
Date: 2 Jul 1994 09:00:43 +0200

In comp.os.linux.development, article <Cs7tr7.236@wg.saar.de>,
  bof@wg.saar.de (Patrick Schaaf) writes:
> 
> Unless I'm misreading patch24.gz, it is broken. The struct file_operations
> is extended by 2 or 3 entries (check_media_change), but only floppy_ops
> sets the new fields. Since file_operations are usually module global
... and the others clear them implicitly. This is a feature of the C
language. RTFK&R. 1.1.24 _does_ work.

-- 
Do not clog intellect's sluices with knowledge of questionable uses.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: igor@mera.itpm.alma-ata.su (Igor Sharfmesser)
Subject: Why autoprobing disabled for eth1-eth3?
Date: 2 Jul 1994 13:40:02 GMT

Hi!

I've installed Linux 1.1.24 and I've tried to install second Ethernet.
Linux did not find it. Looked at drivers/net/Space.c I notice,
autoprobing disabled for all Ethernets except eht0. Why?
After changes in Space.c all works fine.

                                  Igor
--
Igor Sharfmesser, postmaster of irbis.alma-ata.su
Internet: igor@irbis.alma-ata.su
FIDO:     2:5083/11.12



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

From: janusz@NOT-FOR-MAIL (Janusz Zamecki)
Subject: Help: Modules in Linux kernel
Date: 1 Jul 1994 09:05:51 GMT
Reply-To: janusz@ict.pwr.wroc.pl

Hi!
I need more informations about writting dinamicly loaded modules into the
kernel. Where I can get an example programm?

Please, send me response via e-mail:
        janusz@ict.pwr.wroc.pl

Thanks

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

From: sverrehu@ifi.uio.no (Sverre H. Huseby)
Subject: Re: Floppy code broken w. 1.1.23
Date: 2 Jul 1994 16:12:40 +0200


In article <2v33ar$7b3@smurf.noris.de>, urlichs@smurf.noris.de (Matthias Urlichs) writes:
> In comp.os.linux.development, article <Cs7tr7.236@wg.saar.de>,
>   bof@wg.saar.de (Patrick Schaaf) writes:
> > 
> > Unless I'm misreading patch24.gz, it is broken. The struct file_operations
> > is extended by 2 or 3 entries (check_media_change), but only floppy_ops
> > sets the new fields. Since file_operations are usually module global
> ... and the others clear them implicitly. This is a feature of the C
> language. RTFK&R. 1.1.24 _does_ work.

Maybe I misunderstand you all (hope not), but according to the Kernel
Hackers Guide, static variables (the bss segment) may or may not be
initialised to zero depending on the method used for booting. This
differs from `normal' executables.


Sverre.

===========================================================
Sverre H. Huseby                                    Student
sverrehu@ifi.uio.no              University of Oslo, Norway
http://www.ifi.uio.no/~sverrehu

My employer (that's me) is not responsible for my opinions.


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

From: parprods@ecn.uoknor.edu (Dorwin Shields)
Subject: West. Digi. 540 MB Hard drive--HELP!
Date: 2 Jul 1994 14:31:05 GMT

    Is there any way I can get linux to recognize by 540 MB Dos partition?--
Before I upgraded the hard drive a tarred and gzipped my old drive and saved
it on my linux drive -- now I cant restore my dos drive because linux wont
recognize my drive --even if I partition it into a 340 and 200 Mb HD.     
Thanks,
Dorwin

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

From: jmaclean@fox.nstn.ns.ca (James B. MacLean)
Subject: Re: Quirky idea: Remote Virtual Consoles
Date: 2 Jul 1994 11:30:22 -0300

In article <1994Jul1.234329.6336@n5ial.mythical.com> jim@n5ial.mythical.com (Jim Graham) writes:
>From: jim@n5ial.mythical.com (Jim Graham)
>Subject: Re: Quirky idea: Remote Virtual Consoles
>Date: Fri, 1 Jul 1994 23:43:29 GMT

>First, my idea is msdog-based.  Sorry, but the lib that I've got that will
>(for me, at least) help make this work is dog-based, so my ideas are also
>dog-based.  Besides that, it'll make it available on my ancient pc/xt
>clone, so I like it---I might even pull that thing out of storage to try
>this.  :-)   Oh, one thing...my idea uses a library under dog that isn't
>freeware.  If I were to develop the dog end, I'd release my portion to
>freeware (copyrighted freeware probably, but freeware just the same), but
>for someone else to compile it, they'd either have to port it to another
>screen management library or buy a copy of the same one I bought (UltraWin).

I know there exists some libs for screen stuff on SIMTEL, including NCURSES 
for DOS, would these not be an option at this time? I know it would be  new 
interface to learn, but in the end, it's more available for porting to other 
clients.

>Basically, the idea is to have a server running under Linux, and a simple
>VC emulator running under dog.  Until you ask for graphics (e.g., running
>X, svgalib stuff, etc.), the VC emulator can be kept relatively simple.
>I haven't a clue what it would take on the Linux end, but I'm sure there's
>at least *SOME* kernel work (if nothing else, for selection---that is, *IF*
>we're to use selection from the Linux side---we could also put that on the
>server side and handle the rest via the communications link).  If we're to
>add graphics to this, someone else will have to handle that part.

All sounds great. Keep everything spec based as opposed to hardware based so 
that we can run this service on different clients/servers and protocols (not 
only serial). I've already received E-mail and returned DOSEMU's spec sheet 
on this idea, if that was not you :-), E-mail, and I'll pass it along.

>The emulator under dog would simply take the signals from its keyboard
>and send them to the remote Linux machine with instructions as to which
>RVC the data comes from.  The Linux machine would send information to
>the emulator, once again complete with information as to which RVC the
>data is intended for.
>Some type of (very simple) data communications protocol would have to be
>run between the two, and I have some ideas on how to do that, too.

The data structures too. The protocol is a given, but if we look into things 
like mmaping over NFS drives, there should be commonly described structures 
that can be updated in this manner.

>As I envision this right now, all terminal emulation would still be done
>under Linux---the emulator would simply be a smart set of dumb
>terminals....if that makes any sense.  ;-)

JL?,Lutz?,Markkk? I see another layer here. A common server (not just 
DOSEMU) that runs the app and looks after the I/O. Separate from DOSEMU all 
together, just that DOSEMU will run in the interface. Maybe with the right 
setup, DOSEMU would not need to change that much to use it.

>Does anyone consider this a good place to start?  I realize my ideas are
>somewhat disjointed right now, but then, I'm dreaming up parts of this
>(and there's C code forming in the brain) as I type.  :-)  Is anyone
>interested in working together with me on such a plan?  I can handle the
>non-graphics portion of the msdog end and the datacomm link.  Can someone
>else handle any graphics and/or the Linux side?

I'm listening :-). If you've got a game plan, I'm sure the DOSEMU team will 
give you feedback, and possibly some time. Especially when it comes to 
working on the server part. Sounds like an IRC topic.

>If anyone is interested in this idea, please *E-MAIL ME*.  If you post
>here, please add the following line to your headers (except don't comment
>it out like I've done):
># Cc: jim@n5ial.mythical.com

Using this newsreader, I can not do that, but I'll send to you if you do not 
make reference to this posting over a couple of days :-)

>Later,
>   --jim
>73 DE N5IAL (/4)                           < Running Linux 1.0.9 >
>      jim@n5ial.mythical.com                 ICBM: 30.23N 86.32W
>  ||  j.graham@ieee.org          Packet:  N5IAL@W4ZBB (Ft. Walton Beach, FL)
>E-mail me for information about KAMterm (host mode for Kantronics TNCs).

Later,
JES
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
James B. MacLean                    jmaclean@fox.nstn.ns.ca
Department of Education
Nova Scotia, Canada (902) 424-8438

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

From: jmaclean@fox.nstn.ns.ca (James B. MacLean)
Subject: Re: Dosemu & serialport video work?
Date: 2 Jul 1994 11:33:40 -0300

In article <1994Jul2.014544.833@tlc.alcm.org> rwyble@tlc.alcm.org (Richard J. Wyble) writes:
>Subject: Dosemu & serialport video work?
>From: rwyble@tlc.alcm.org (Richard J. Wyble)
>Date: Sat, 2 Jul 1994 01:45:44 GMT


>Presently running Linux kernel 1.0, dosemu .50pl1. At the console terminal
>works quite handsomely with an ATI Graphics card.
>Over serial lines, however, the video is =not= good.
>Has it improved since the .50pl1 version? What can one do to tweak it along?

Quite honestly, it has improved enough to completely warrant upgrading to 
atleast 1.0.9 and applying the included kernel patch (or going to a 1.1.12+ 
kernel).

>-- 
>  rwyble@alcm.org  | Assoc Lutheran Church Musicians | Minister of Music
>  Richard J. Wyble | PO Box 16575                    | Trinity Lutheran Church
>  (508) 799-7924   | Worcester MA 01601              | Worcester MA

Later,
JES
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
James B. MacLean                    jmaclean@fox.nstn.ns.ca
Department of Education
Nova Scotia, Canada (902) 424-8438

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

From: chapmra@u.washington.edu (Randy Chapman)
Crossposted-To: alt.os.linux,comp.os.linux.misc
Subject: Re: CD Recorder Driver?
Date: 1 Jul 1994 15:57:40 GMT

In article <STEFAN.94Jul1095743@pippi.tu-bs.de>,
Stefan Markgraf <stefan@pippi.tu-bs.de> wrote:
>>I have heard a rumour that there is a Phillips CD-R (recordable CD) driver
>>for Linux.  Does anyone know anything about this driver?  Anyone actually
>>been able to use the CD-R with linux?
>Do you really believe you can convert a CD-ROM into a writable CD?
>I think there was a warning that this driver is a virus 
>which destroys the harddisk.

Actually, that was a DOS based program for Chinon drives that offered to 
convert a normal CD-ROM drive into a CD-R drive.

However, Philips (and others) make _real_ CD-R drives; they normally 
attach via SCSI and are rather EXPENSIVE... ($3k if you're lucky)  As for 
a Linux driver, I've seen queries but never any definite answers :(

Randy




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

From: delman@mipg.upenn.edu (Delman Lee)
Subject: Re: atdisk2 patches and 1.1.23 - Help !!!!!!!!!!!!!!
Date: 30 Jun 94 21:33:42 GMT

In article <2uti7d$n68@sparky.sterling.com> dwb@ITD.Sterling.COM (David Boyd) writes:

   I went through the effort to hand apply the atdisk2 patches to
   my copy of 1.1.23 with the IDE Speedups applied.  Has anyone ever
   gotten this to work??  The patches seemed very straight forward,
   but I get continous Controller reset messages from the driver
   for the second controller.  

   Could the multimode IDE patches be the problem (i.e. does anyone have
   two controllers wokring with 1.1.23)?

The stock atdisk2 patch is for linux sources without the multimode
patch. I haven't looked at the multimode patch lately. Last time I
looked, I have to patch the atdisk2 patch to work with the multimode
stuff. Since my IDE drive can't handle multimode, I haven't been
keeping that up to date with the latest multimode patch.

Anyway, I will make an atdisk2 diff that will work with sources that
have the multimode patch applied. (I am moving house this
weekend, so may can't do much work till afterwards). 

Cheers, Delman.
--
______________________________________________________________________

  Delman Lee                                 Tel.: +1-215-662-6780
  Medical Image Processing Group,            Fax.: +1-215-898-9145
  University of Pennsylvania,
  4/F Blockley Hall, 423 Guardian Drive,                         
  Philadelphia, PA 19104-6021,
  U.S.A..                            Internet: delman@mipg.upenn.edu
______________________________________________________________________

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

From: jmaclean@fox.nstn.ns.ca (James B. MacLean)
Subject: Re: Quirky idea: Remote Virtual Consoles : More Thoughts
Date: 1 Jul 1994 14:54:21 -0300

In article <2ur5rl$2ht@zola.apana.org.au> lukeh@zola.apana.org.au (Luke Howard) writes:
>From: lukeh@zola.apana.org.au (Luke Howard)
>Subject: Re: Quirky idea: Remote Virtual Consoles
>Date: 29 Jun 1994 16:54:44 +1000

>Byron A Jeff (byron@gemini.cc.gatech.edu) wrote:
>: Jeff, it's just not the same.
>: I don't want to telnet into the machine. I want my alt and ctl keys to act
>: exactly the same way on the RVC as on a real VC. I want selection.\
>: When I sit down at the RVC it should look and act exactly the same as the
>: console attached to the Linux box.

>I suppose it comes down to whether you want something Linux specific or 
>something generic. Personally I'd be inclined to go for the Linux 
>specific way, or at least model it on the present situation, but I doubt 
>you'd gain much from doing so. 

What I would like :-)... Is something that's open down to the specs so that 
we could implement the client part on ANY thing. I believe we need some 
standards (eh JL ?) that dictate how all the necesary info is to be passed, 
and what info is to be passed. Then DOSEMU could be a server that drives 
clients, as well as other 'console' type servers could be used to drive 
clients. I guess it's kinda like the X approach where you know what your 
sending/receiving, but it's your business doing the displaying. It ain't 
gonna be a walk in the park, but it would provide another level of internet 
interfacing that's above telnet, yet not as specific in implementation as X.

>I would love a program like this BTW... (especially as NCSA Telnet seems 
>to be cursed against me). In terms of implementation, perhaps it may be 
>possible to hack the sources for NCSA Telnet? You'll still get in.telnetd 
>rather than whatever getty looks like, but this is cosmetic; and adding 
>mouse support to look like selection shouldn't be too difficult. Decent 
>support for the console termcap would also be nice so that dosemu 
>works... (never tried this over NCSA mind you).

Right on the money. Atleast in my eyes. First there was telnet, now there is 
whatever so that another level of functionality is added. Something as 
simple as remote mice is not accounted for in telnet. What about remote 
access of local resources? If the specs are open enough, we could share/talk 
many things within this link (serial/ethernet/satalite). Currently a 
protocol covers what we transfer data back on forth on (TCP/IP, IPX, etc...) 
and different services have been added to this to allow accessing info 
accross the wire, but in this manner, this link would describe how to do 
everything accross the link. Likely it would exploit all that exists now, 
but from another angle. We want `pc-anywhere` type of interface control to 
the point that you could run a remote Windows session in a window of your 
local X machine which is just a PC connected to Linux via this link :-)

>But some kind of way of deploying this XT which is sitting near me would 
>be rather useful... :-)

Aggreed.

>: Thanks for the suggestion.
>-- 
>                      Luke Howard, Luke.Howard@apana.org.au
>                   URL http://zola.apana.org.au/0/zola/people
>                                Utlisez Linux!!!

I do talk too much :-(,
JES
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
James B. MacLean                    jmaclean@fox.nstn.ns.ca
Department of Education
Nova Scotia, Canada (902) 424-8438

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

From: ioi@eniac.seas.upenn.edu (Ioi Kim Lam)
Subject: Linux Development Documentation
Date: 1 Jul 1994 18:30:36 GMT

Hi,

        I am in the process of planning to write (another) Unix-like
OS for the 386. I will use Linux as my development platform. Could
anyone give pointers to the information listed below?

        - linux .o file format
        - linux .a file format
        - linux .out file format
        - documentation about these programs (on the linux platform):
                gcc
                as   (or gas)
                ld   (esp: how to use it to link the kernel image)
                as86
                ld86
        - any other interesting docs about linux development?

Please mail your reply to 

        ioi@eniac.seas.upenn.edu

Thanks in advance!

Ioi..
                

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

Crossposted-To: comp.unix.sys5.r4,comp.unix.unixware
From: msohnius@novell.co.uk (Martin Sohnius)
Subject: Re: ISDN device driver
Date: Fri, 1 Jul 1994 16:55:46 GMT

Stanley Henderson (stanh@hal.COM) wrote:
: I am looking for some examples of devices drivers for ISDN controllers.
: In particular, I would like one for the Digiboard ISDN board.

: Has anyone had experience with an ISDN device driver?

Two companies that make ISDN boards and have certified support
for UnixWare, are

        netCS Informationstechnik GmbH
        Feuerbachstr. 47
        12163 Berlin
        Germany
        Tel. +49-30-856 9990

and
        BinTech Computersysteme GmbH
        Willstaetterstr. 30
        90449 Nuernberg
        Germany
        Tel. +49-911-99 6750

Obviously, these are commercial, and won't give you their source, but
perhaps if you ask nicely?

--
                        +--------------------------------------------+
Martin Sohnius          | Dr. Faustus (Unix version):                |
Novell Labs Europe      |                                            |
Bracknell, England      |       chmod ugo=rw soul                    |
+44-344-724031          +--------------------------------------------+
                        (I speak for myself, not for Novell or anyone else.)

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

From: luke@research.canon.oz.au (Luke Kendall)
Subject: Linux seems to perform terribly for large directories
Date: 30 Jun 94 06:35:45 GMT

I have strong suspicion that Linux has a problem with large
directories.  An early pointer to this, was that doing an `ls'
on a directory with (say) 5000 files, took several minutes
to begin producing output.  This is _far_ slower than on other
versions of Unix.

The 2nd indicator was what happened when I used cpio to read a large
number of files from a floppy containing files from the Linux
newsgroups: (in particular, the voluminous comp.os.linux.help).

(My pattern of use was to dump a whole lot of files to my home machine,
and every now and then read them and delete uninteresting articles.
I started loading from around news item 20000; I'm now up in the
early 40,000's.  So about 20,000 files have been added and removed.)

There was 40Mb free at the time; (the hard disc had recently been filled
to within 500kb of Full).  Then I lots of junk.

So, this time, reading 761 files from the floppy (2295 blocks,
i.e. 1.15Mb), the elapsed time was something like 7 minutes!
Normally reading a floppy like this takes between 1 and 2 minutes.

I timed a 2nd, similar floppy of files.  Elapsed time just over 4
minutes; 20secs user, 117secs system, 49% of CPU.  I believe that
the process was swift until it read a fixed amount from floppy into
internal memory, and then slowed down dramatically when writing the
files out to the hard disc (judging by the screen output & drive
access light).

Just listing the files on the floppy was as fast as normal.

Reading a floppy into /tmp was normal speed.  Moving the files into
the right directory took only seconds.

Reading a floppy into a directory that had contained far fewer files
also took only a reasonable amount of time.

Processes running were an xview X session with a performance monitor
and clock in the background (as normal).

A ps of the cpio process about 2/3 or 3/4 of the way through the
process showed it had used 1m30s CPU time.

Processor is a 486DX33, with a VLB controller and a 340Mb Western
Digital IDE drive, 8Mb of memory, running Linux 0.99.13.  The
floppies are 1.44Mb.

So: what gives?  Have others noticed this problem?

luke

-- 
Luke Kendall, Senior Software Engineer.      | Net:   luke@research.canon.oz.au
Canon Information Systems Research Australia | Phone: +61 2 805 2982
P.O. Box 313 North Ryde, NSW, Australia 2113 | Fax:   +61 2 805 2929

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

From: psteindl@il.us.swissbank.com (Philippe Steindl)
Subject: PPC mailing list?
Reply-To: ilg@imp.ch
Date: Sat, 2 Jul 1994 18:46:53 GMT

Hia,

is there a PPC port mailing list or such? Just to listen, not to shout...

Thanx

Philippe Steindl

--
====================+===================================================
Philippe Steindl    |                  Any opinions expressed are my own
E-mail: ilg@imp.ch  |                  and not necessarily those of the 
                    |                  Swiss Bank Corporation.
====================+===================================================

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


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