Subject: Linux-Development Digest #882
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 20:13:04 EDT

Linux-Development Digest #882, Volume #1          Sat, 2 Jul 94 20:13:04 EDT

Contents:
  verbose xxgdb error (Daniel W. Moore)
  composed keys suport for deadkeys? (Christian Saucier)
  Re: NetBEUI (Leslie Mikesell)
  Re: System lock ups: NCR 53c810 driver problem? (Matthias Rabe)
  Re: NetBEUI (Barry Lynam)
  Re: Floppy code broken w. 1.1.23 (Rob Janssen)
  Re: Quirky idea: Remote Virtual Consoles (Jordan Hazen)
  <q> FAQ on BSD > LinuX porting C src.. (Tim Bass (Network Systems Engineer))
  Re: Can DOSEMU execute a unix shell or program?? (Matthias Rabe)
  Re: Dosemu & serialport video work? (Rob Janssen)
  Re: Dedicated SCSI swap drive? (Wayne Schlitt)
  SOL'N: DOSEMU/Netware (Andrew Anderson)
  Re: 1.1.24 & Slackware BUG??? (Paul J. Gans)

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

From: dwmoore@clark.net (Daniel W. Moore)
Subject: verbose xxgdb error
Date: 2 Jul 1994 19:45:06 GMT

 
Hi,

Does anyone know why xxgdb would produce the following error on      
_every_ attempt at a run, step, cont, etc. ?
                                                         
    [tcsetpgrp failed in terminal_inferior: Not a typewriter]

It only does this under xxgdb ; gdb by itself behaves a bit better.
                                                                  
Actually, xxgdb is quite a spiffy tool, if if weren't for this one
rather annoying trait. 

I am using Slackware 1.2.0, Linux kernel 1.0.8, XFree 2.0, and            
xxgdb 1.08 with GDB 4.12.
    
TIA,
       Dan                                 

dwmoore@clark.net    ----     ( aggh what a GUI mess!! )

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

From: saucc00@DMI.USherb.CA (Christian Saucier)
Subject: composed keys suport for deadkeys?
Date: Fri, 1 Jul 1994 17:55:49 GMT

I'm starting to write a new keyboard map (for an without X).  It's a 
"canadian french" keyboard.  This keyboard uses deadkeys.  For example,
you press the "grave" button and then the "e" and you've got a \`e.

I looked at the loadkeys and dumpkeys programs and it seems like I can
do what I want only if my "kernel has compose key support" (according to
the dumpkeys man page).  What I'm trying to do is this:

keycode 40 = dead_grave
keycode 30 = a
compose '`' 'a' to '\`a'

Does this makes sense?   has anybody else ever did some deadkeys support
for their keyboard mapping?  If so, how?

Any help is appreciated,

Christian.

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

From: les@MCS.COM (Leslie Mikesell)
Subject: Re: NetBEUI
Date: 2 Jul 1994 15:20:03 -0500

In article <1994Jul2.115158.3344@news.uit.no>,
Rogon Fateless <rogon@engstad.tromsomh.no> wrote:

>I have investigated this a bit, and I have come to the conclusion
>that making NetBios/BEUI in the kernel as a file-system is the way
>to go. So, now all I have to do is to dig into kernel programming...

This is the most efficient way to go, of course, but an interesting
variation would be to make a program that worked as an SMB client
and an NFS server so a single machine could act as a gateway for
all of the NFS machines on the net.  This program could be written
more portably as well since it doesn't need to know the details
of even the local file system interface. 

I haven't followed the whole thread here - I hope you are aware
of "samba" which is the server side of a netbios-over-tcp/ip
connection, and that NETBEUI is a transport layer variation that
would need to be supported by the network interface.

Les Mikesell
  les@mcs.comm

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

From: rabe@mathematik.uni-bielefeld.de (Matthias Rabe)
Subject: Re: System lock ups: NCR 53c810 driver problem?
Date: Fri, 1 Jul 1994 18:55:16 GMT

In article <2uv540$q61@trondviggo.nvg.unit.no>,
Stig Venaas <venaas@nvg.unit.no> wrote:
>I also started with 13, and patched up to 19. When I tried to patch
>in the NCR patch I got some rejects and the kernel didn't compile
>cleanly. Didn't this happen to you?

I too got some rejects. After applying the rejected patches by hand, the 
kernel compiled and it seems to run fine.

-- 
rabe@mathematik.uni-bielefeld.de                          Matthias Rabe
Universit"at Bielefeld                            Privat: Avenwedder Str. 494
U5-133                                                    D 33335 G"utersloh
Tel.: (0521) 106-3871                                     Tel.: (05209) 6673

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

From: lynam@qut.edu.au (Barry Lynam)
Subject: Re: NetBEUI
Reply-To: B.Lynam@qut.edu.au
Date: Fri, 1 Jul 94 05:11:05 GMT

In article <Cs6H3z.IC@pe1chl.ampr.org>, rob@pe1chl.ampr.org (Rob
Janssen) writes:
|> In <1994Jun29.130804.10785@news.uit.no> rogon@doom.tromsomh.no (Rogon
|> the Fateless) writes:
|> 
|> >I have always wondered how Windows for Workgroups v. 3.11
|> >works, apparently it uses some sort of protocol called 
|> >NetBEUI for communication.  
|> 
|> NetBEUI (or NetBIOS) is not a protocol, it is an interface to a
|> protocol.
|> It is specific to DOS, and not applicable to Linux
No, NetBEUI is a complete protocol stack like IP, IPX, DECNet, AppleTalk
etc.
It is not specific to DOS. NT has it. VAX Machines can use it.

My advice is to not use it because it is non-routable. On a small network it
is not a bad thing but on a large network it is bad. If you have a large net
use TCPIP instead of NetBEUI.

|> 
|> >Where can one find documentation on this? Is it free or
|> >proprietary? Has anyone thought of making a driver of some
|> >sort to incorporate this for Linux?
|> 
|> >I would really like to be able to use our orginazation's
|> >file-servers, since most of them use WfW3.11.
|> 
|> Get the SAMBA SMB-server, this allows you to access the Linux filesystem
|> from PC's running Windows for Workgroups.
|>
SAMBA won't let you use LANManager/WfW3.11/WINNT etc as a client. It make's
your Unix box be a server to these clients. There is a program in SAMBA that
is ftp like. 
 
|> >Is this a topic for the DosEMU and/or Wine team?
|> 
|> NetBIOS could be added as part of dosemu, but as dosemu cannot run Windows
|> it would not solve your problem.  It could be interesting for other
|> reasons.  Maybe sometime I'll do it.
|> 
|> Rob
|> -- 
|> -------------------------------------------------------------------------
|> | Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
|> | e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
|> -------------------------------------------------------------------------

-- 
+------------------------------------------------------------------+
| Barry Lynam                           EMail:  B.Lynam@qut.edu.au |
| Communications - Network Services     Phone:  +61 7 864 2883     |
| Computing Services                    Fax:    +61 7 864 1343     |
| Queensland University of Technology   Postal: GPO Box 2434       |
| Brisbane AUSTRALIA                            Brisbane 4001      |
|                                               AUSTRALIA          |
|--"I may not agree with your argument, but I'll defend your ------|
+---right to express it"-------------------------------------------+


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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Floppy code broken w. 1.1.23
Date: 30 Jun 94 22:01:35 GMT
Reply-To: pe1chl@rabo.nl

In <Cs7tr7.236@wg.saar.de> bof@wg.saar.de (Patrick Schaaf) writes:

>rob@pe1chl.ampr.org (Rob Janssen) writes:
>>In <1994Jun28.195537.16667@odin.diku.dk> duke@diku.dk (Dennis Henriksen) writes:
>>>Just upgrade to version 1.1.23. Has anyone tried to wriote to a 5.25"
>>>1.2Mb disk with success ?

>>Try 1.1.24, there were again patches to the floppy code...

>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
>structures, the new check_disk_change, which is always called on mount,
>will access random memory contents past the struct memory. It can jump
>to arbitrary locations. This should affect all device mounts, and
>SCSI removable media devices.

>I'll send this to the kernel channel, too.  I didn't apply the patch and
>try it out; if I'm not correct, please flame me to death...

Well, I'm running 1.1.24 and it did not jump into random locations
on floppy or cdrom mounts...
Most probably, all the drivers that do not init these fields will leave
NULL pointers in there and they won't be called.

When I saw this while reading the patch, I thought "well, here may be
the solution to the problems I see when swapping a CD without unmounting
it first".  But I did not checkout the patch in detail.

Playing a bit with the CDROM drive again gave the familiar:

Jun 30 23:58:55 sys3 linux: CD-ROM I/O error: dev 0b00, sector 400
Jun 30 23:59:18 sys3 last message repeated 2 times
Jun 30 23:59:28 sys3 linux: CD-ROM I/O error: dev 0b00, sector 0
Jun 30 23:59:40 sys3 linux: Weird - unlocked, clean and not uptodate buffer on list 0 b00 200
Jun 30 23:59:40 sys3 linux: Weird - unlocked, clean and not uptodate buffer on list 0 b00 0
Jun 30 23:59:40 sys3 linux: Weird - unlocked, clean and not uptodate buffer on list 0 b00 200
Jun 30 23:59:40 sys3 linux: Weird - unlocked, clean and not uptodate buffer on list 0 b00 0
Jul  1 00:00:03 sys3 linux: CD-ROM I/O error: dev 0b00, sector 64
Jul  1 00:00:03 sys3 linux: isofs_read_super: bread failed, dev 0xb00 iso_blknum 16
Jul  1 00:00:16 sys3 linux: CD-ROM I/O error: dev 0b00, sector 64
Jul  1 00:00:16 sys3 linux: isofs_read_super: bread failed, dev 0xb00 iso_blknum 16

It seems like not much has changed yet...

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: jnh@kzin.cen.ufl.edu (Jordan Hazen)
Subject: Re: Quirky idea: Remote Virtual Consoles
Date: 1 Jul 1994 18:55:12 GMT

Some more suggestions for anyone thinking about the
remote-console-server idea:

1)      Take a look at the "dual-mon" kernel patch first-- it changes
all of the console I/O routines so they can handle more than one
screen, in order to support a secondary MDA adapter for extra
consoles.  This should provide some of the framework for redirecting
VC I/O to a remote system.  Unfortunately, the patch is rather old
(made against 0.99pl13 I think), and is hard to get working for even
its intended uses.  The main reason I'm still using the 1.0 kernel
is that I don't want to go through the hassle of applying dual-mon
again to the 1.1 sources...

2)      Support for the PLIP protocol on the remote-server side would
be nice, since that would allow laptops, etc. without Ether cards to
serve as remote consoles.  Failing that, maybe high-speed SLIP could
be used?

3) How about making hardware on the remote-server machine available as
virtual /dev entries for the Linux box?  Handling console traffic
should be negligible load for even a 286, so there should be plenty of
CPU time left over to handle this.  Access to block devices (floppy
and hard disks) would be useful too-- run DOS apps. off the remote
host under DOSEMU and avoid wasteful duplication!

--
Jordan.

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

From: bass@cais.cais.com (Tim Bass (Network Systems Engineer))
Subject: <q> FAQ on BSD > LinuX porting C src..
Date: 2 Jul 1994 21:27:39 GMT

What a nightmare!!!!  Not that I don't love the abuse, but porting
to LinuX is a pain...Maybe too many 18 hour days on 15 differnet
UNIX platforms and I'm a lamer again. HELP!!

Is there a FAQ or some good advice on source code porting to LinuX?

For example, I pulled the Steven's _TCPIP Illustrated_ source off
ftp.uu.net...all the socket tools, etc.  header files are missing, 
missing...

So, I log into a SUNOS box or an HP-UX box, and grap some *.h files.
Tweek the sourse and add -DLINUX statement..... errors out the ying yang.

Of course, I could print out the source and pull out the LinuX system
call man pgs - do a real port.  There must be an easier way!

Any help would be appreciated.  What am I missing (execept for gray 
matter!!) ??


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

From: rabe@mathematik.uni-bielefeld.de (Matthias Rabe)
Subject: Re: Can DOSEMU execute a unix shell or program??
Date: Sat, 2 Jul 1994 21:23:00 GMT

In article <Cs95Bv.wJ@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
>In <2uvj61$67p@gap.cco.caltech.edu> iotov@cco.caltech.edu (Mihail S. Iotov) writes:
>> I think what he means is something like :
>
>>linux$ dos -execute c:\quicken\q.exe
>
>>That would be a nifty feature.
>
>It is not too difficult to do that.  Just write a small shell script that
>writes the command in a .BAT file, and include a call to that .BAT file
>in the AUTOEXEC.BAT, followed by a delete of the .BAT file.
>
>something like:
>
>#!/bin/sh
>echo $* >/dos/start.bat
>exec dos

And what, if you run two such jobs about the same time...?

-- 
rabe@mathematik.uni-bielefeld.de                          Matthias Rabe
Universit"at Bielefeld                            Privat: Avenwedder Str. 494
U5-133                                                    D 33335 G"utersloh
Tel.: (0521) 106-3871                                     Tel.: (05209) 6673

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Dosemu & serialport video work?
Reply-To: pe1chl@rabo.nl
Date: Sat, 2 Jul 1994 12:42:46 GMT

In <1994Jul2.014544.833@tlc.alcm.org> rwyble@tlc.alcm.org (Richard J. Wyble) writes:


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

It has improved a lot in one area (handling the exceptions caused by each
video access) and deteriorated in another (doing the actual updates to the
screen now sends the entire screen much too often).
You have to try it yourself to judge it.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: Dedicated SCSI swap drive?
Reply-To: wayne@cse.unl.edu
Date: Sat, 2 Jul 1994 21:18:56 GMT

In article <1994Jul1.002047.17190@midway.uchicago.edu> lair@kimbark.uchicago.edu (Scott A. Laird) writes:
> In article <WAYNE.94Jun30000433@backbone.uucp>,
> Wayne Schlitt <wayne@cse.unl.edu> wrote:
> >
> >It is almost always better to have a bunch of small drives vs one
> >large drive.  Adding a swap disk isn't a bad idea.  If you get a disk
> >that is say 60-80MB, you might want to put /tmp and /usr/tmp on the
> >drive too.
> 
> While I agree with most of this, I'm not sure that putting the swap
> and tmp space on a seperate, slower drive will help performance.  I
> doubt that any of the <100 Mb SCSI drives out there can top 1 Mb/sec,
> and I suspect that most of them (can you say ST-296N?) are more like
> 200-300k/sec, tops.  With both tmp and swap space, I suspect that most
> of the reads and writes will be fairly long and sequential, and will
> benefit most from the fast transfer of a big drive.
> 
> Of course, the best way to speed up both of these is to add more RAM.



The key advantage to having multiple disk is that it cuts down on the
time spent seeking.  Even if two disks have real slow transfer rates,
they will be faster than one disk that has to do a lot more seeking.



How sequential your access to swap is going to be depends on a
lot of different things.  If Linux lays out swap space contiguously
based on the virtual addresses of the program _and_ Linux's VM system
detects sequentially accessed pages and does page ahead _and_ the
program you are running uses more of virtual memory than you have
physically, _and_ the program accesses the memory sequentially, then
yes, you would get nice sequential access on swap.  I think that this
is going to be _very_ rare.  Besides, as you said, this is the perfect
case for more RAM.

More likely, you will start paging because you are starting to run a
new program, or a program that has been iconified for a long time, or
you are read/writing a large file and you need more buffer cache.  In
these cases, having one disk doing I/O for the swap while another disk
can do I/O to the executable file or data file is going to be a big
win, even if the swap disk is fairly slow.  You are going to overlap
I/O with seeks, your seeks won't be for as far a distance, and you
might not have to seek at all if each disk can stay in one spot.



-wayne


-- 
Our reasoning goes something like this:  "If I want it, I need it.  If
I need it, it's my right.  If it's my right, someone should give it to
me.  Or else I'll sue."     -- Newsweek June 27, 1994

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

From: andersoa@news.db.erau.edu (Andrew Anderson)
Subject: SOL'N: DOSEMU/Netware
Date: 1 Jul 94 01:37:03 GMT

Well, I finally came up with a hardware/software solution that provides an
acceptable solution to my problems...

I finally stole a 286 to run the SOSS program to provide access
to the CD-ROMS on my Netware file server.  This allows me to have one
login to my Netware server providing access to files for multiple DOSEMU
sessions.  This isn't as elegant as what I'd hoped for, but it works.

This will work for now, as long as I don't add more than 3 additional 
CD-ROMS (almost out of re-directable driver letters in DOSEMU!).  
I still have to keep a DOS partition around, though, because the 
database search software is DOS based. :(  Kind of interesting to
see a screen and a half of mounts, though! ;)

Does anyone know if a faster machine with more memory (than the 1meg
286 I'm currently using) will significantly speed NFS access?  And just to
be crazy, has anyone tried running SOSS *through* DOSEMU? :)

If anyone gets the NCP (?) ipx/spx working (or at least in alpha),
I'm interested in helping you test it.
--
|===========================================================================|
|  Andrew Anderson                              andersoa@erau.db.erau.edu   |
|  Novell Network System Administrator          andersoa@bart.db.erau.edu   |
|  Linux System Administrator                   andrew@wilbur.db.erau.edu   |
|                                                                           |
| I don't speak for ERAU, and God knows I don't want them to speak for me!  | 
|===========================================================================|

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

From: gans@scholar.chem.nyu.edu (Paul J. Gans)
Subject: Re: 1.1.24 & Slackware BUG???
Date: 2 Jul 1994 19:32:51 GMT
Reply-To: gans@scholar.chem.nyu.edu

Bogdan Urma (bogdan@crl.com) wrote:


:      I've just come across a VERY VERY weird problem with the
: new 1.1.24 kernel, and possibly earlier 1.1.xx kernels. It has
: to do with the 'pkgtool' program in Slackware 1.2.0.x. 

: Problem: 
:         When I run pkgtool and choose remove packages from the
: menu, a list of all installed packages comes up. Well here's the weird
: thing: While moving the cursor with the up and down keys to select packages
: to remove, the program crashes and exits!! The up and down keys, which
: work normally anywhere else, seem to send weird characters in remove section
: of pkgtool. If you have a new kernel and Slackware 1.2.0.x, please try this
: and let me know if it happens to you too. Scroll up and down a few times
: in the remove part of pkgtool and see if the program crashes.

: Please try this at home !

Yup, just tried it with 1.1.18 and Slackware 1.2.0.x.  Pkgtool worked
fine while I tapped the arrow keys.  When I held the (down) arrow
key down, the package crashed.  It looks to me as if it is a buffer
overrun problem of some sort -- that the shell program couldn't read
keypresses fast enough.

    ---- Paul J. Gans   [gans@scholar.chem.nyu.edu]



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


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