Subject: Linux-Development Digest #158
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:     Mon, 11 Oct 93 18:13:09 EDT

Linux-Development Digest #158, Volume #1         Mon, 11 Oct 93 18:13:09 EDT

Contents:
  Minor bug in shutdown (Julian Francis Day)
  Re: possible bug in virtual console switching (Scott D. Heavner)
  Re: CFC/CFI: XSysadmin (James H. Haynes)
  Re: possible bug in virtual console switching (Joel M. Hoffman)
  Re: Page fault (Matthias Urlichs)
  Re: PPP for Linux? Well... almost as good (Matthias Urlichs)
  Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development") (Tim J.Benham)
  Re: RFD: Removal of group "comp.os.linux.development" (Karsten Steffens)
  Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development") (Brandon S. Allbery)

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

From: jfd0@aber.ac.uk (Julian Francis Day)
Subject: Minor bug in shutdown
Date: Mon, 11 Oct 1993 19:12:53 GMT

I've noticed that if one has output held on a Virtual Console (beyond ?buffer?
size) then when you try to shutdown, because it cannot write to the other
console, it hangs until the user presses <Ctrl> <Q>. I have been unable to
check whether this also applies to other consoles, but it could cause the
nanve user hastle.

-- 
Julian Day
=====
No sig.                 (jfd0@aber.ac.uk)

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

From: sdh@fishmonger.nouucp (Scott D. Heavner)
Subject: Re: possible bug in virtual console switching
Date: Mon, 11 Oct 1993 17:30:58 GMT
Reply-To: sdh@po.cwru.edu

Risto Kankkunen (kankkune@cs.Helsinki.FI) wrote:
> >I find the same thing (with dosemu and other VC's).  So, there's
> >clearly something wrong.  And what's wrong is the VC switching, and in
> >particular, that part of it that both X and dosemu use.  Further,
> >whatever it is about the keyboard that bash uses to go into vi mode is
> >be changed, so that should provide a clue.  If I had the sources to
> >bash handy I might even try to track it down myself....

> There was a bug in the keyboard driver that made it confuse the state of
> modifier keys when switching between raw and nonraw consoles. I thought
> that was fixed in pl13, at least a patch for that was sent to Linus. (I
> can't currently verify that with dosemu or X, I don't have a working
> version of them installed.)

        This is exactly the problem.  If you switch from a graphics
console (XFree86, dosemu, (s)vgalib) to a regular tty console (text),
the keyboard functions as if you are holding down one of the shift
keys (alt, ctl, shift).  To recover, just switch to two consecutive
text consoles.  Of course this is not a true solution and I would be
interested in the patch.  When I asked about this a while back, all the
responses said that I needed a new loadkeys, but since I was
using the US map, I never bothered.


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

From: haynes@cats.ucsc.edu (James H. Haynes)
Subject: Re: CFC/CFI: XSysadmin
Date: 11 Oct 1993 21:01:27 GMT


Personally, I don't care for elaborate graphics interfaces for sysadmin
tasks, but that's a matter of personal choice.

We should ask some of the guys at MIT to tell us about their 'mkserv'
stuff.  The idea is that the basic machine as-installed is a one user
workstation; but you can say mkserv with various arguments to turn it
into a printer server, or an NFS server, or some other kind of function.


Here's a somewhat out of date man page.

.\"     $Header: /afs/rel-eng.athena.mit.edu/project/release/current/source/athena/config/update/RCS/mkserv.8,v 1.6 91/08/14 17:36:52 probe Exp $
.\"
.\" Copyright 1990 by the Massachusetts Institute of Technology
.\" All rights reserved.
.\"
.TH MKSERV 8 "April 4, 1990" "MIT Project Athena"
.ds ]W MIT Project Athena
.SH NAME
mkserv \- add/delete services on an Athena workstation
.SH SYNOPSIS
.B mkserv
[
.BI -service ...
] [
.BI service ...
] ...
.SH DESCRIPTION
.I Mkserv
allows one to add services and delete services provided by a private
workstation (the
.B PUBLIC
variable in 
.I /etc/athena/rc.conf
must be set to \fIfalse\fR).  Services added via this interface will be
preserved through Athena workstation updates.
.PP
This interface will copy the necessary programs and data files local to
the workstation.  To the best of the program's ability, configuration
files will also be set up.  However, in some cases, the users must
complete the job by setting up a few configuration files - what the user
must complete will be described at the end of the procedure.  The
configuration files the user is expected to setup will also be preserved
during Athena workstation updates, so once a service is added, the user
may even opt to let the workstation take automatic updates (set the
.B AUTOUPDATE
variable in
.I /etc/athena/rc.conf
to \fItrue\fR).
.PP
When removing services, not all the configuration files can necessarily
be restored to their previous state.  Some files have been
previously described as being the proper ones to modify, and
.I mkserv
also modifies some of these same configuration files.  Because of this
conflict of interest,
.I mkserv
modifies configuration files only if there is reasonable certainty that
it was the agent of a particular change.
.PP
Prefixing a service with a "-" indicates that the service should be
removed from the workstation, whereas, the service name without a "-"
indicates that the specified service should be added.  Three special
services exist for convenience:
.TP 8
.B clean
Remove all previously specified services from a workstation.
.TP
.B public
Remove all previously specified services from a workstation and change
the
.B PUBLIC
variable in
.I /etc/athena/rc.conf
to \fItrue\fR).  Upon a reboot, the standard cleanup procedure that is
in the workstation boot sequence will detect that the machine is a
public workstation and reset any changes in the configuration files.
.TP
.B update
Ensure that all the binaries and configuration files match what is
expected from the current release.
.PP
The following is a list of supported \fBmkserv\fP options.  Not all of
these options are available on all platforms, however.
.TP 8
.B discuss
Configure the workstation to be a discuss server.
.TP
.B mail
Configure the workstation to be able to receive mail.
.TP
.B nfs
Configure the workstation to provide NFS service.
.TP
.B pop
Configure the workstation to provide POP mail service.
.TP
.B remote
Configure the workstation such that remote login access is possible.
.PP
Other services do exist, but are still considered
.I experimental.
Use of other services is at your own risk.
.PP
The update procedure copies files from the system packs to the local
machine so that the machine may provide service while the machine does
not have the system packs mounted.  These files are placed in:
.TP 15
.I /site/server
on VAX and RT machines running BSD 4.3 Unix.
.TP
.I /var/server
on machines running Ultrix.
.PP
The workstation maintainer may also customize the update procedure
through the use of two special files.  These special files should be
placed in the top-level directory that \fBmkserv\fR uses (eg.
\fI/var/server\fR on Ultrix machines).  Any other customizations that
are placed in this directory will be deleted by \fBmkserv\fR.
.TP 15
.B .private.sync
ammends the SyncTree rules in
.B /usr/athena/lib/update/services.sync
that list the files needing to be copied locally.  If the presence of
this file causes \fBSyncTree\fR to exit with a non-zero exit status, the
update will be considered unsuccessful, and no symbolic links to
the server directory will be left on the root partition.
.TP
.B .private
is a script or program that can be executed under 
.I /bin/sh
that allows the workstation maintainer to add other local
customizations to the machine with ease.  Examples of such
customizations would be the editing of various configuration files or
installation of special binaries not present in the standard Athena
release.  This file must exit with a zero exit status for the update
to be considered successful.
.PP
The workstation maintainer should understand the ramifications of using
customizations.  If mistakes are present in his customization files, the
workstation may be left in an inconsistent or unusable state.  Since the
customizations are run as part of the \fBmkserv\fR procedure, mistakes
in the customizations may cause the \fBmkserv\fR process to die abruptly
or possibly misconfigure the workstation.  If incorrect semantics in the
customization files simply cause the workstation to believe the update
is unsuccessful, the workstation version will be \fBUpdate\fR, thus
requiring the maintainer to diagnose the problem before another update
can be taken.
.SH EXAMPLES
.TP 5
.B mkserv clean remote nfs
Remove any previous services enabled on the workstation and
will configure the workstation to provide both NFS and remote login
service.
.TP
.B mkserv -discuss mail
Remove the discuss service and add mail service to the workstation.
.SH BUGS
Better determination of configuration files changed by the script is
needed so that removal of services is more thorough.
.PP
Some of the service additions should request input from the user to set
up configuration files if they have not been setup already.
.SH FILES
/etc/athena/rc.conf
.br
/site/server/*
.br
/usr/athena/lib/update/config
.br
/usr/athena/lib/update/final.sync
.br
/usr/athena/lib/update/services.sync
.br
/usr/athena/lib/update/*.add
.br
/usr/athena/lib/update/*.del
.SH SEE ALSO
synctree(1)
.SH AUTHOR
Richard P. Basch (MIT-Project Athena)
.SH COPYRIGHT
Copyright 1990 by the Massachusetts Institute of Technology.
.br
All Rights Reserved.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint!  But ya gotta know the territory!"
        Meredith Willson: "The Music Man"


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

From: joel@rac2.wam.umd.edu (Joel M. Hoffman)
Subject: Re: possible bug in virtual console switching
Date: Mon, 11 Oct 1993 21:01:04 GMT

In article <29c2o5$dfi@klaava.Helsinki.FI> kankkune@cs.Helsinki.FI (Risto Kankkunen) writes:
>>I find the same thing (with dosemu and other VC's).  So, there's
>>clearly something wrong.  And what's wrong is the VC switching, and in
>>[...]
>
>There was a bug in the keyboard driver that made it confuse the state of
>modifier keys when switching between raw and nonraw consoles. I thought
>that was fixed in pl13, at least a patch for that was sent to Linus. (I
>can't currently verify that with dosemu or X, I don't have a working
>version of them installed.)


Well, I'm running pl12, so that would make sense.  Can anyone confirm
(or deny) that the bug was fixed in pl13?

While on the topic, are there any documented problems with pl13 that
do not affect pl12, or is it completely safe to upgrade?

Thanks.

-Joel
(joel@wam.umd.edu)

-- 
=============================================================================
|_|~~ Germany, Europe. 1943.    "The diameter of the bomb was 30 centimeters,
__|~| 16 Million DEAD.           and the diameter of its destruction, about 7
                                meters, and in it four killed and 11 wounded. 
 cnc  Bosnia, Europe. 1993.     And around these, in a larger circle of  pain
 cnc  HOW MANY MORE?          and time,  are scattered two  hospitals and one
                          cemetery.   But the young woman who was  buried  in
                    the place from where she came, at a distance of more than
             than 100 kilometers, enlarges the circle considerably.   And the 
      lonely man who is mourning her death in a distant  country incorporates
into the circle the whole world.  And I won't speak of the cry of the orphans
that reaches God's chair and from there makes the circle endless and godless."
=============================================================================
     Tell Clinton to stop the genocide:  president@whitehouse.gov

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

From: urlichs@smurf.sub.org (Matthias Urlichs)
Subject: Re: Page fault
Date: 11 Oct 1993 20:20:18 +0100

In comp.os.linux.development, article <1993Oct8.092506.20032@kullmar.se>,
  pand@kullmar.se (Peter Andersson) writes:
> gt8134b@prism.gatech.EDU (Howlin' Bob) writes:
> 
> What I need is to let my program handle the causing
> SIGSYSV as this:

It's sigSEGv.

> 1 - change the protection of the page to allow read & write
> 2 - single step the instruction who caused the SIGSYSV
> 3 - change the protection back
> Got any idea how to handle this?
> 
Why do you want to do this in the first place? It seems that singlestepping 
every instruction that refers to such a page would be hideously slow.

> >>  some extra data like where it was trying to write or read and
> >>  if it is possible, set the single step trap.
> >If you were in the kernel, you would read CR2.  Since you're not,
> >it's not a valid question.
> But how does gdb handle it? It is able to single step one instruction!
> 
No. It's able to tell the kernel to please set that flag for the process in 
question, through the ptrace() system call. This is not something you'll want 
to do in a normal program.

-- 
Resistance is useless. Stand still.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg   | EMail: urlichs@smurf.sub.org
Schleiermacherstra_e 12  \  Unix+Linux+Mac     | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing      42

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

From: urlichs@smurf.sub.org (Matthias Urlichs)
Subject: Re: PPP for Linux? Well... almost as good
Date: 9 Oct 1993 22:13:12 +0100

In comp.os.linux.development, article <1993Oct6.185344.23025@cognos.com>,
  naubertp@cognos.COM (Patrick Naubert) writes:
> 
> Andrew R. Tefft (teffta@cs690-3.erie.ge.com) wrote:
> : About once a week on average someone asks if there is PPP for Linux.
> : Nobody ever answers so the general consensus is no -- it seems that
> : everyone with the capability to produce PPP is satisfied with SLIP.
> 
> Well, *I* need PPP.  I am about to connect a line to a PPP server full-time
> in order to connect a BBS to the Internet full-time.  I need to have a sync
> line to my host, and I as know (heard) only PPP will support that kind
> of link.
> 
Actually, a sync line, meaning a synchronous serial interface, needs external 
hardware because standard serial ports cannot support a serial data stream. 
For one, the HDLC bitstuffing technique is ridiculously expensive in 
software; for another, you need at least a clock input line. I am not aware 
of any interfaces / drivers for Linux; I'd be interested if somebody has a 
solution.

> - I will list the functions necessary to run the PPP core, and these functions
>   will need to be reverse-engineered into the linux kernel. I need a Linux
>   kernel hacker.  PLease line up, one at a time :)
> 
I already have incorporated most if not all the core functions into Linux
by simply ;-) porting the whole networking code from NetBSD to Linux.

Right now, this code is a severe hack, and as I've been offline for a week 
due to a bad SCSI problem (still waiting for two NCR53C90B SCSI interface 
chips for the second harddisk and the tape drive... backups are a good idea 
but kind of useless if you can't read the tapes) getting that code into 
alpha-testable shape is still a week or two away.

It's also not a general solution, I'm afraid, because some people consider 
the legal issues (the dreaded but mostly-dead BSD/USL lawsuit for one) 
sufficiently murky to not want any BSD code in the kernel. Or so it seems to 
me.

-- 
You doubt my good faith?
Let's just say my faith would be strengthened by a gesture from you. Such
  as powering down your disruptors.
                -- Tomalak and Picard, "The Enemy", stardate 43349.2
-- 
Matthias Urlichs        \ XLink-POP N|rnberg   | EMail: urlichs@smurf.sub.org
Schleiermacherstra_e 12  \  Unix+Linux+Mac     | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing      42

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

Crossposted-To: news.groups
From: benti4@cserve.cs.adfa.oz.au (Tim J.Benham)
Subject: Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development")
Date: Mon, 11 Oct 1993 20:54:23 GMT

In article <29bqbf$m1s@soc2.pop.psu.edu> barr@pop.psu.edu (David Barr) writes:
> [...]
>       What do you say about making c.o.l.d moderated?
>
>--Dave

Too slow.
--
                "If there is any fixed star in our constitutional
                   constellation, it is that no official, high or petty, can
Tim J.Benham         prescribe what shall be orthodox in politics, nationalism,
benti4@cs.adfa.oz.au   religion, or other matters of opinion or force citizens
                         to confess by word or act their faith therein."

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

Crossposted-To: news.groups
From: karsten@kshome.ruhr.de (Karsten Steffens)
Subject: Re: RFD: Removal of group "comp.os.linux.development"
Date: Mon, 11 Oct 1993 19:48:34 GMT

Tim Peoples (tep@rzrbyte.fay.ar.us) wrote:

:      a small yet vocal group of active readers of c.o.l.d have ever
:      so rightiously taken it upon themselves to be the self appointed
:      guardians of content for messages posted to c.o.l.d; and
:      this group of readers has made public announcement that the
:      asking of questions will not be tolerated on the group c.o.l.d; and

:      there is no need for a USENET newsgroup in which questions are
:      not tolerated;

Bravo! Hope you now hit exactly the point. The people around Ian Jackson
behave as if the c.o.l.d would be their private garden, and anybody coming
in there, is being flamed to death. Some time ago those flamers were content
by sending flames to the person daring to ask questions which were totally
under the level of consciousness of those immortal highnesses, but now they
started to do the flaming in the list itself. That's definitely too much
to stand. Ian and the others, please learn the following: development is
not only going on in the area of kernel hacking and device driver writing. If
a person has problems for instance in porting applications, this is also
development, and of course it belongs into c.o.l.d., even if there exist
lists related to those applications. This should be so, because the problems
porting an application to linux, which runs smoothly under another OS, are
due to linux, and are of MAJOR interest to people using linux. So they should
have a source of information at hands, and c.o.l.d is the natural place for
it.

It seems as if most of the stuff which made the Jacksons flame the writers
of cold is related to porting anything to linux, starting from elm, tin
up to X-related stuff or even games(!), I suggest a compromise.

        a) Let c.o.l.d be reserved for linux kernel and driver stuff

        b) make a new list c.o.l.p concerning PORTABILITY question.
           The subject of this list should be all the problems arising
           from porting applications to linux, and this list should be
           definitely open to anybody's question, as silly as they might
           look for the housekeepers of c.o.l.d

Please discuss, and please comment. Maybe we should really make another
small splitup, this might be a better solution then just closing c.o.l.d

In German there is a famous word, which I translate here (roughly) to
english:           
                The wiser man gives in, only the fool insists...

Regards, Karsten
-- 
==================>         Karsten Steffens        <=====================
   karsten@kshome.ruhr.de          |      steffens@ikp.uni-muenster.de
Marl - close to Recklinghausen     |         Institut fuer Kernphysik
  North of the Ruhrgebiet          |   Westf.Wilhelms-Universitaet Muenster

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

Crossposted-To: news.groups
From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development")
Date: Mon, 11 Oct 1993 21:19:26 GMT

In article <jsmCEqnC1.II1@netcom.com> jsm@netcom.com (John Miller) writes:
>Folks, my apologies if this was already hashed during the
>vote, but would it help any if the group were called
>
>       comp.os.linux.developers

Care to guess how many Unix newbies used to post to comp.unix.wizards because
"obviously, I need a wizard to help me", ignoring comp.unix.questions
entirely?

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."  ---dmeggins@aix1.uottawa.ca

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


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