Subject: Linux-Development Digest #732
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:     Wed, 18 May 94 21:13:08 EDT

Linux-Development Digest #732, Volume #1         Wed, 18 May 94 21:13:08 EDT

Contents:
  GNU Hurd Task List and Call for Volunteers (Michael I Bushnell)
  Re: Transputer port of LINUX (Harvey J. Stein)
  Re: SIGHUP - Deep Kernal Guts question! (Theodore Ts'o)
  Re: Anybody working on BSD dump porting? (matthew "pipeman" mead)
  Re: Two suggestions that might speed up Linux. (Steve Kann)
  p-thread (pre-emptive) package: volunteers gladly accepted :) (Marino Ladavac)
  Where is Linux PPP (Brian Quandt)
  Re: setlocale() bug or feature? (Brandon S. Allbery)
  Re: In defence of variety (was Re: Distributions considered harmful) (Brandon S. Allbery)
  Re: Anybody working on BSD dump porting? (Andrew R. Tefft)
  Linux for Power Macs (Nancy R. Evans)
  Linux for Power Macs (Nancy R. Evans)
  Re: Distributions considered harmful (Andrew R. Tefft)
  Modem hangup? (Scarrow)
  Re: Two suggestions that might speed up Linux. (Robert Sanders)

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

From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell)
Crossposted-To: gnu.misc.discuss,comp.os.mach,comp.os.linux.misc,comp.unix.pc-clone.32bit
Subject: GNU Hurd Task List and Call for Volunteers
Date: 18 May 1994 17:54:47 GMT


Now that the Hurd can run (albeit haltingly) on its own, it is
possible for people who do not have Mach 3.0 single-servers to
contribute without much trouble.  (However, if you don't have a
single-server, you probably won't be able to use a debugger, but that
doesn't mean you can't do debugging, right?)

We at the FSF don't have any expertise in setting up Mach 3.0
machines; the machines that we do development on belong to the Open
Software Foundation and were set up by them.  So one of the things on
the task list is to organize things so that people (like us and most
of you) who don't know how to do it can do it.  It's not impossible to
figure out, it's just a pain and a marvelous thing for a volunteer to
do.

You can get Mach 3.0 from CMU; you get the C library and the Hurd from
us.  You need the soon-to-be-released version 1.07.6 of the C library
and the latest Hurd snapshot (as well as our special version of MiG)
from alpha.gnu.ai.mit.edu.

All our work is based upon i386.  The Hurd (except for a few programs;
see the Hurd README file) is machine independent.  The C library
should not be too much trouble to port.  Ports and information about
porting difficulty for either of these are greatly desired.

The Hurd is not yet self-hosting.  While you are welcome to fetch the
code and put things together, it is not likely that you will have a
useful system right now.  But you might be able to do significant work
(see the task list below).  And, even if you can't do significant
work, I'm interested in hearing about any places where you had
particular difficulty.

If you want to start on one of these tasks, please let me know so I
can keep track of volunteers properly.  This task list will be updated
periodically; gnu@prep.ai.mit.edu always has the latest version.

        -mib

GNU Hurd Task List Version 1.0.

If you would like to work on one of these, please contact mib@gnu.ai.mit.edu.


Mach 3.0 Work

  o Mach 3.0 comes with CMU makefiles that depend on a drecky environment.  
  It would be very helpful to have makefiles and installation stuff so
  that it worked well for cross-compilation between systems and used 
  GNU tools.

  o MiG needs to be made able to support cross-compilation.

  o A replacement for MiG that understood C .h files.

  o Bootstrap tools and documentation to help people set up Mach 3.0
  machines if they already have Linux; if they already have Net BSD;
  if they don't have anything.

  o Mach 3.0 needs to provide support for task virtual timers similar
  in functionality to the Unix ITIMER_PROF and ITIMER_VIRTUAL timers.

  o Mach 3.0 needs to provide a way for users to do statistical PC
  profiling similar to the Unix profil system call.

  o Mach 3.0 needs a facility to automatically send task and thread 
  status on task/thread exit to a port that can only be changed by
  a privileged user; this would be used to implement process 
  accounting.

  o Mach 3.0 needs a facility to find out what task is the parent of
  a given task.

  o Mach 3.0 needs a facility to find out which pages of a task's
  address space are in core to implement Unix's mincore call.

  o Mach 3.0 needs a facility to do msync.

  o Mach 3.0 needs a replacement for MEMORY_OBJECT_COPY_CALL that 
  works at least for the cases needed in ordinary files.  (Write mib if
  you want to know what the problem is and some ideas about how to
  solve it.)

  o Mach 3.0 needs proxy memory objects.  (mib can tell you what these
  are and why they are important.)

  o Mach 3.0 needs a way to do per-task resource counters that are
  accessible to servers called by the task.

  o Mach 3.0 needs facilities to implement resource limits of various sorts.

  o Mach 3.0 needs a way to have a thread's CPU time statistics
  include time spent by servers on its behalf.

  o Of course, free ports are always necessary to machines that don't
  already have free ports.

  o Much work can be done doing research in how to improve Mach VM
  performance and timesharing scheduling policy.


Hurd work (these are brief descriptions; mib can give more information):

  o We need a translator for /dev.

  o We need a replacement for utmp and wtmp that understands the
  Hurd `login collection' concept.  Programs like who and finger
  then need to be changed to use this.

  o We need some existing shell programs changed to do Hurd things:
  like ls, su, fsck, tar, cpio, etc.

  o Some new programs need to be written: login, getty, ps, tools
  for new filesystem features.

  o Shadow directory translators.  (Roland has the beginnings of this.)

  o A system for write, send, talkd and so forth to bleep users;
  this should be integrated with the utmp replacement above.

  o X.

  o A filesystem for /tmp that uses virtual memory instead of disk.

  o Filesystem implementations (using libdiskfs) for other popular
  formats, especially the Linux formats as well as MSDOG.

  o Transparent FTP translator.  
  
  o NFS client implementation.  You should start with BSD's 4.4 code
  and support the extensions they support; don't worry about Hurd
  extensions right now.  (The server we want to write ourselves
  because it will probably involve changing the Hurd interfaces.)

  o A fancy terminal driver that uses readline and supports detach/attach.

--
+1 617 623 3248 (H)    |   The soul of Jonathan was bound to the soul of David,
+1 617 253 8568 (W)   -+-   and Jonathan loved him as his own soul.
1105 Broadway          |  Then Jonathan made a covenant with David
Somerville, MA 02144   |    because he loved him as his own soul.

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

Subject: Re: Transputer port of LINUX
From: hjstein@sunset.huji.ac.il (Harvey J. Stein)
Date: 18 May 94 14:35:55


Since so many people think that a transputer port of Linux would be so
difficult, what about if we just wanted the ability to compile a
program, load it into the transputer board, run it, & look at the
results?  This would still be *very* useful, for number crunching, for
example.

--
Harvey J. Stein
Berger Financial Research

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

From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: 18 May 1994 15:46:44 -0400
Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)

   From: nate@loreli.ftl.fl.us (Sean Puckett)
   Date: Fri, 13 May 1994 04:25:16 GMT

   We're developing a BBS under Linux 1.0, and we've found that 
   many applications, including bash, ksh and perl, do not pass
   on the HUP signal from do_tty_hangup (tty_io.c)'s call to 
   kill_sl (exit.c).

   The kernal apparently wants to send just one HUP/CONT pair
   only to the session leader, and none to any other processes
   on the lost tty.  The session leader (shell) is sucessfully
   killed on hangup, every time, but its children are not.

   We need all active processes attached to a lost tty to get
   a proper HUP signal.  We're considering patching tty_io.c
   to do what we want, but first we need to know if the kernal 
   was designed to act 'broken' on purpose -- that is, if there 
   is something else we should be doing besides patching the 
   kernal to effect the change we need.

It's designed to act that way because the POSIX international standard
specifies that it works that way.  And no, it's not broken.  It is the
responsibility of the session leader to decide whether or not the SIGHUP
signal should be passed on to its children or not.  If it decides it
wants to, it should establish a signal handler for SIGHUP, and propagate
the signal to its children as appropriate.

I would advise you to do this instead of modifying the kernel to violate
the POSIX specification.  Among other things, it will make it easier to
port your BBS to other POSIX-complaint systems in the future.

                                                - Ted

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

From: mmead@csugrad.cs.vt.edu (matthew "pipeman" mead)
Crossposted-To: comp.os.linux.help
Subject: Re: Anybody working on BSD dump porting?
Date: 18 May 1994 11:33:11 -0400

In article <CpyxL3.AzH@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
>Because of the many filesystems that Linux supports, trying to port
>something like "dump" is not simple, and IMHO not a good idea.
>
>You are better off making backups with "tar" or "cpio".

        What if you need to backup over the net?  There's rdump, but I assume
that won't work for the same reasons that dump won't ... how would dumping to a
disk mounted on a machine elsewhere on your local net be accomplished? :-)


-- 
-- Matthew C. Mead --       | To learn recursivity you must know recursivity.
mmead@csugrad.cs.vt.edu     | To learn recursivity you ... oh wait that's
ztalk voicemail accepted at |-------------------------------------\ iteration
-slapshot.async.vt.edu-!!!! | http://slapshot.async.vt.edu/~mmead |----------

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

From: stevek@panix.com (Steve Kann)
Subject: Re: Two suggestions that might speed up Linux.
Date: 18 May 1994 11:40:09 -0400

William O Smith (wos@dcs.warwick.ac.uk) wrote:
: Suggestion 1:  Compressed buffers.  On fast machines, if there is idle
:          time, and spare buffer space, how about compressing the
:          disk buffers, storing both versions (compressed and un-
:          compressed) until memory gets tight, then just keeping
:          the compressed version (if it saves much space).  Presumably
:          if the machine becomes fast enough, decompressing memory
:          should be faster than loading off disk.

I think this is a really interesting idea...  And the basics of the
implementation might not be too hard.  The only difficult thing to do
might be the memory-management.  I am not sure how the kernel allocates
memory for the buffer cache, but I would suppose it is in page-size
increments -- this compression thing would need to use a smaller page
size for allocation to be effective.  And putting this together with the
cluster patches might also add a little spice to such a venture...

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

From: lan_lada@aaf.alcatel.at (Marino Ladavac)
Subject: p-thread (pre-emptive) package: volunteers gladly accepted :)
Reply-To: lan_lada@aaf.alcatel.at
Date: Wed, 18 May 1994 15:32:35 GMT

                POSIX 1003.4a compliant thread package

We have started to work on implementing the thread-package library and it is
expected to be available till December, albeit perhaps not fully functional.

We do not as yet know whether to use the clone() syscall, but the approach is
under consideration (looking at kernel, scratching head :)

We are: Marino Ladavac (m.ladavac@aaf.alcatel.at) 
and Davor Jadrijevic (davj@apoirb.irb.hr)

Help is gladly accepted--we *will* bother you about it :)

Basically, if there's anyone out there willing to join, please send us note. 

/Marino "Alby" Ladavac


---
Proof by Intimidation:
        "I'm bigger, therefore I'm right."
#include<std/disclaimer.h>


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

From: quandt@saucer.cc.umr.edu (Brian Quandt)
Subject: Where is Linux PPP
Date: Wed, 18 May 1994 15:12:22 GMT

Sorry if this smacks of FAQ ignorance, but, where do I find PPP
for Linux?  I write this not having tried sunsite; it was been
unreachable all morning!

Thanks,

Bill Balloni   
balloni@fltsim.mdc.com


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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: setlocale() bug or feature?
Date: Wed, 18 May 1994 16:01:52 GMT

In article <2rd2nh$ekf@fbi-news.informatik.uni-dortmund.de>, ruprecht@euklid.informatik.uni-dortmund.de (Nick Ruprecht) says:
+---------------
| >And: Am I right in thinking that LC_MESSAGES should allow any value to
| >be specified?
| 
| Actually, the last statement is true for all LC categories. The ANSI
| standard defines only two locales: the C locale (invoked by default or
| by setlocale(LC_ALL,"C")) and the default locale (setlocale(LC_ALL,"")).
| As far as ANSI C is concerned, all other locales are implementation
| specific. For example, on Suns, the existing locales are controlled by
+------------->8

I believe XPG2/XPG3 (X/Open specs) specify some locales, e.g. iso_8859_1.

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
The FUDs at Microsoft are shouting "Kill The Wabi!"

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: In defence of variety (was Re: Distributions considered harmful)
Date: Wed, 18 May 1994 16:04:04 GMT

In article <QUINLAN.94May17214634@pollux.cs.bucknell.edu>, quinlan@spectrum.cs.bucknell.edu says:
+---------------
| If you haven't bothered to bring something up a second time, then
| don't blame it on FSSTND.  In my FSSTND archives, I have a *single*
+------------->8

The flames I got in mail from various high-placed folks on the list were a
bit too emphatic.  I saw little point in continuing.

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
The FUDs at Microsoft are shouting "Kill The Wabi!"

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

From: teffta@cs690-3.erie.ge.com (Andrew R. Tefft)
Subject: Re: Anybody working on BSD dump porting?
Reply-To: teffta@cs690-3.erie.ge.com
Date: Wed, 18 May 1994 17:24:49 GMT

I think an ext2fsdump would be an excellent project for some expert
filesystem hacker (a port is not really feasible). You really can't
beat restore, as far as text interfaces go, for restoring individual
files or directories from backup media. And dump does incrementals well.


---

Andy Tefft               - new, expanded .sig -     teffta@cs690-3.erie.ge.com



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

From: nre+@pitt.edu (Nancy R. Evans)
Subject: Linux for Power Macs
Date: 17 May 94 12:55:47 GMT

Good Day,

    I read in PowerPC News that there is development for a version of linux
on the power macs.  My question is simple. Is it being written for the NuBus
or PCI card or both.  I would like to see it written for NuBus. I have a
6100/60 and I would love to run unix on it if possible. Please send
responses to nre+@pitt.edu.

Thanks in advance.
Nancy R. Evans

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

From: nre+@pitt.edu (Nancy R. Evans)
Subject: Linux for Power Macs
Date: 17 May 94 12:55:57 GMT

Good Day,

    I read in PowerPC News that there is development for a version of linux
on the power macs.  My question is simple. Is it being written for the NuBus
or PCI card or both.  I would like to see it written for NuBus. I have a
6100/60 and I would love to run unix on it if possible. Please send
responses to nre+@pitt.edu.

Thanks in advance.
Nancy R. Evans

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

From: teffta@cs690-3.erie.ge.com (Andrew R. Tefft)
Subject: Re: Distributions considered harmful
Reply-To: teffta@cs690-3.erie.ge.com
Date: Wed, 18 May 1994 17:32:53 GMT

In article 2458@kf8nh.wariat.org, bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>In article <2rbcg5$pj1@news.tamu.edu>, drs0587@net.tamu.edu says:
>+---------------
>| On a Sun there is no operating system distribution competition, and
>| as a result, you see almost no movement toward including significant
>| features/tools that we have come to expect in any decent linux 
>| distribution. Why does Solaris still not have emacs, mosaic, archie,
>| ftptool, mtools, perl, tcl/tk, gnu tar, tn3270, gzip, and patch,
>+------------->8
>
>Your argument here falls flat with one counter-question:  Why doesn't SCO
>provide emacs, Mosaic, archie, ftptool, mtools, perl, tcl/tk, ...?  After all,

Gee, the reason nobody includes this stuff is probably because they aren't
willing to support it without ownership of the code, and the authors aren't
about to give that away (or sell it).

---

Andy Tefft               - new, expanded .sig -     teffta@cs690-3.erie.ge.com



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

From: bairds@ee.pdx.edu (Scarrow)
Subject: Modem hangup?
Date: 17 May 1994 10:37:04 -0700

I'm developing some software for a small company (actually it's been in use
for a while now, but we're having a few problems) involving automated modem
transactions, and I've had some difficulty getting Linux to drop the DTR
line.  I've tried setting the line flags, setting the output baud rate to
zero, etc.  I noticed that kermit seems to drop it sometimes, so I'm going
to go take a look at that source, but was just gonna pop the question here
to see if anyone else has had problems with this.

-- 
  Scarrow (bairds@ee.pdx.edu)    | "By all means, take the moral high ground --
            <> [] ()             | all that heavenly backlighting makes you a
                                 | much easier target."  --Solomon Short

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

From: gt8134b@prism.gatech.edu (Robert Sanders)
Subject: Re: Two suggestions that might speed up Linux.
Date: 18 May 1994 13:46:54 -0400

stevek@panix.com (Steve Kann) writes:

>William O Smith (wos@dcs.warwick.ac.uk) wrote:
>: Suggestion 1:  Compressed buffers.  On fast machines, if there is idle
>:         time, and spare buffer space, how about compressing the
>:         disk buffers, storing both versions (compressed and un-
>:         compressed) until memory gets tight, then just keeping
>:         the compressed version (if it saves much space).  Presumably
>:         if the machine becomes fast enough, decompressing memory
>:         should be faster than loading off disk.

>I think this is a really interesting idea...  And the basics of the

And a really bad one.  It's kinda amusing how people will want
to compress everything.  I imagine quite a few of them have tried
to gzexe gzip...

First off, if things aren't being used, there really isn't much
use in keeping them in the buffer cache.  That's why old buffers get
flushed.  To be used, buffers must get uncompressed.  Therefore,
to stay compressed for any sensible length of time, a buffer would
have to be unused.  But unused buffers have no place in-memory: 
they stay on disk.

Now, the reason why buffers can't just get uncompressed at read()
or write() time: the kernel uses buffers for more than just disk
I/O: any mmap()ed file shares buffer space.  So, if I mmap()
/lib/libc.so.4.5.21 (which is what uselib() does), I have the
disk buffers resident.  Even if noone read()s that file, they need to
be resident and uncompressed so I can access libc from all the
programs that mmap() it.

People, if you don't have enough disk space, buy more.  Linux
is great partly because it's fast; this sort of bad hackery will
slow it to a backwards crawl.  Then the same people who wanted 
compressed swap partitions will complain because their machine
is slow when they swap.


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

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


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