lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
oldlinux-files/mail-archive/linux-activists/Volume1/Volume1/digest102
gohigh a778c607a4 add directory mail-archive
2024-02-19 00:25:02 -05:00

560 lines
22 KiB
Plaintext
Raw Permalink Blame History

From: Digestifier <Linux-Activists-Request@news-digests.mit.edu>
To: Linux-Activists@news-digests.mit.edu
Reply-To: Linux-Activists@news-digests.mit.edu
Date: Fri, 13 Mar 92 07:30:09 EST
Subject: Linux-Activists Digest #102
Linux-Activists Digest #102, Volume #1 Fri, 13 Mar 92 07:30:09 EST
Contents:
Re: Linux 0.95 (Jim Winstead Jr.)
Re: linux 0.95 kernel building (Werner Almesberger)
Re: Linux 0.95 woes (Rogier Wolff)
Localtion of init and mount (Rogier Wolff)
Re: rz & sz in linux (Rogier Wolff)
Device driver organization -> loadable device drivers. (Rogier Wolff)
Linux source code reductions necessary or not? (Rogier Wolff)
Termcap entry of Linux consoles: lost lines in vi. (Rogier Wolff)
Documentation: an offer/an idea (I Reid)
Writing to kmem allowable? includes patch. (Rogier Wolff)
Re: Linux File System Document Revision 1.0 (Michael Haardt)
----------------------------------------------------------------------------
From: jwinstea@jarthur.claremont.edu (Jim Winstead Jr.)
Subject: Re: Linux 0.95
Date: 13 Mar 92 04:41:55 GMT
In article <LONGSHOT.92Mar12214011@att2.mankato.msus.edu> longshot@att2.mankato.msus.edu (Erik Green) writes:
> If we can get these things and also some sort of simple installation
>document together, we should be able to get quite a lot of people
>using Linux :-)
Some of these issues will be addressed with the release of 0.95a, expected
in a week or so. Pfdisk is already available for Linux, and fdisk should
be corrected to handle the new partition naming scheme, from all the
indications I've gotten. More room will be freed up on the root disk
for programs like pfdisk, tar and compress with the substitution of ash
for bash. More on all this later...
>BTW: We also need something that does the patching of the boot image
>more or less automatically.
The rdev.c program posted just recently does this already, and this will
replace the rootdev program on the 0.95 distribution root floppy. Not
only does it duplicate the functionality of rootdev when called with
no arguments, but it also allows patching of boot-disk images (or disks)
by specifying the image and root device on the command line.
>I'll be able to start writing some of these in about a month, when I get
>my new motherboard. In the meantime, though, does anyone feel like a
>little challenge?
In about a month, the things you're asking for should already be on the
distributed root disk. There will always be other things to do, though.
--
Jim Winstead Jr. (CSci '95) | "Catch a fish!"
Harvey Mudd College | -Geddy Lee,
jwinstea@jarthur.Claremont.EDU | San Diego Sports Arena
Disclaimer: Mine, not theirs! | January 20, 1992
------------------------------
From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
Subject: Re: linux 0.95 kernel building
Date: Fri, 13 Mar 1992 10:12:31 GMT
In article <3103@inca.comlab.ox.ac.uk> jon@robots.ox.ac.uk (Jon Tombs) writes:
> I have now seen enough posts to know it wasn't my install at fault (I hope).
> It seems the new 0.95 kernel will not compile fork.c or console.c with the
> -O option (compiler died on signal xx), I've seen this beforee on SUNs
> using gcc so I take its a generic compiler bug?
Maybe I'm just lucky, but the 0.95 kernel compiled without any major pro-
blems on my system under Linux 0.95 with gcc 1.40. I just had to uncomment
the GCC_OPT = -fcombine-regs lines in kernel/Makefile, lib/Makefile and
kernel/chr_dev/Makefile
Because I only have 4 MB RAM, I had to add about 1 MB of swap space to
compile kernel/chr_dev/console.c. (dd if=/dev/hda of=/swap bs=128k count=8;
mkswap /swap 1000; swapon /swap - yes, the 1000 is a bit paranoid ;-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ETH Zuerich, CH almesber@nessie.cs.id.ethz.ch /
/ IFW A44 Tel. +41 1 254 7213 almesberger@rzvax.ethz.ch /
/_BITNET:_ALMESBER@CZHETH5A__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/
------------------------------
From: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Subject: Re: Linux 0.95 woes
Date: 13 Mar 92 09:55:32 GMT
In alt.os.linux someone@matt.ksu.ksu.edu writes:
>Here's yet another user having problems getting linux 0.95 up and running. I
>am experiencing the same problems with it giving the floppy reset when I insert
>the boot disk, but it does continue after saying this about 15 times. The real
>problem is when I go to try to mount the harddisk. It will let me make the file
>system, but when I type mount /dev/hda2 /mnt the drive runs for a bit, then
>comes back and says mount: error 2. This happens no matter what partition I
>try to mount, and no matter what size of partition (not that this should really
>make a difference anyway). Can anyone help me? I'm running this on an Everex
>486/25 with a 211 Meg IDE hard drive and a vga screen. Any and all help would
>be appreciated. Thanx in advance
Error 2 is a "directory or file not found" error. This means that you should
carefully check wether /dev/xxxsd and /mnt exist. However I solved it by
creating a few subdirs on the /mnt thing. Also try mounting on
a different mount point. e.g. /user or /tmp . Mail Linus if you can reproduce
the problem.
Roger
--
If the opposite of "pro" is "con", what is the opposite of "progress"?
(stolen from kadokev@iitvax ==? technews@iitmax.iit.edu)
EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
------------------------------
From: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Subject: Localtion of init and mount
Date: 13 Mar 92 10:30:28 GMT
Reply-To: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Hi everyone,
At this moment the "init" program is housed under /bin. I think that it
should be moved to /etc. The standard under unix systems is that programs
that normal users will never use do not go in /bin or /usr/bin. Init is
a program that is execed by the system to keep spawning login programs
on the ttys. I wouldn't even know what would happen if it were executed
by a normal user....
To change this, you should add a
#define INITPATH "/etc/init"
at the beginning of linux/init/main.c, and then change the two occurances
of "/bin/init" to INITPATH.
This same story, but slightly less convincing can be told about
mount and umount. These are found on all unix computers that I've worked
with in /etc. I think we should stick with the tradition.
(I type "/etc/mount" by instinct, for me it's less trouble typing
"/etc/mount" than having to think about it, and type "mount")
Sun has tried to tidy up the /etc directory. This has resulted in moving
most of the binaries out of the /etc/ directory to /usr/etc. However to
remain compatible they have a whole wood of soft links in /etc to the
binaries they moved to /usr/etc. In this case I think that it is best
to keep it simple and simply put them in /etc.
Roger Wolff
--
If the opposite of "pro" is "con", what is the opposite of "progress"?
(stolen from kadokev@iitvax ==? technews@iitmax.iit.edu)
EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
------------------------------
From: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Subject: Re: rz & sz in linux
Date: 13 Mar 92 09:58:57 GMT
dugan@spider.wri.com (Jon Dugan) writes:
>I picked up the sz & rz sources from somewhere, and compiled them
>without a hitch, but I am unable to figure out how to allow them to
>work.
>I tried:
>rz >/dev/tty64
>but that simply generated timeout errors... has anyone used rz
>with linux yet? It should be a LOT better than kermit..
zmodem is a protocol, it reqires actions from both sides of the
communication line. RZ will thus have to receive data, and send
acknowledges over the modem.
Therefore you should use:
rz </dev/tty64 >/dev/tty64
I use a script rzz with this command in it.
Roger
--
If the opposite of "pro" is "con", what is the opposite of "progress"?
(stolen from kadokev@iitvax ==? technews@iitmax.iit.edu)
EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
------------------------------
From: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Subject: Device driver organization -> loadable device drivers.
Date: 13 Mar 92 10:33:27 GMT
Reply-To: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Hi everyone,
( Source code from Linux is written with > in front, source code which
I propose as new code is written with # in front. Note that I've not
yet tried to compile this code, so it may contain syntax errors, but
it is the intention that counts in this case.)
To read and write to devices, there are routines like:
(taken from char_dev.c at the bottom, already patched by me.)
> int char_rw(int rw,struct inode * inode, struct file * filp, char * buf,
> int count)
> {
> unsigned int major,minor;
> crw_ptr call_addr;
>
> major = MAJOR(inode->i_rdev);
> minor = MINOR(inode->i_rdev);
> if (major >= NRDEVS)
> return -ENODEV;
> if (!(call_addr = crw_table[major]))
> return -ENODEV;
> return call_addr(rw,minor,buf,count,&filp->f_pos,filp->f_flags);
> }
that use a table which holds the addresses of the routines to call.
However there are also places in the kernel that do not use such a
nice structure:
(From init/main.c:)
> tty_init();
> time_init();
> hd_init();
> floppy_init();
This should also be solved with a table like above.
Using the table will allow compiling into the kernel a few empty
device drivers which can be loaded at runtime!
For instance
# struct Devices {
# int (*init)();
# int (*readwrite)();
# int (*ioctl)();
# int numberofminors;
# } devicelist = {
# /* initroutine, read/write , ioctrl ,numberofminors */
# {fd_init ,fd_rw ,fd_ioctl ,32},
# {hd_init ,hd_rw ,NULL /*?*/ ,10},
# {tty_init ,tty_rw ,tty_ioctl ,256},
# {NULL ,NULLi ,NULL ,0}
# };
This would allow modifying the readwrite routine to the following:
# int char_rw(int rw,struct inode * inode, struct file * filp, char * buf,
# int count)
# {
# unsigned int major,minor;
# crw_ptr call_addr;
#
# major = MAJOR(inode->i_rdev);
# minor = MINOR(inode->i_rdev);
# if (major >= NRDEVS)
# return -ENODEV;
# if (minor >= devicelist[major].numberofminors)
# return -ENODEV; /* Linus writes EIO, I think ENODEV is better */
# if (!(call_addr = devicelist[major].readwrite))
# return -ENODEV;
# return call_addr(rw,minor,buf,count,&filp->f_pos,filp->f_flags);
# }
and on similar grounds, the init routine can be tidied up:
#initdevices ()
#{
#int i;
#
#for (i=0;i<NRDEVS;i++)
# {
# if (devicelist[i].init != NULL)
# devicelist[i].numberofminors =
# devicelist[i].init (devicelist[i].numberofminors);
# /* The init routines can detect the hardware that they need,
# and adjust the number of minors that they will support on
# the running configuration. For instance hd_init detects wether
# there is a second harddisk installed, and adjusts the # minors,
# They should return 0 for no hardware. */
# }
#}
And loading a device driver would be something like:
# doloaddevice (char * fname)
# {
# char *start;
#
# if (!suser ()) return -EACCES;
#
# if (curnumerofdevices >= maxnumberofdevices)
# return -EIO;
#
# if (mapintokernelmemory (fname,&start) < 0)
# return -Esomthing;
#
# devicelist[curnumberofdevices].init = start;
# devicelist[curnumberofdevices].nrofminors = (int (*)())start (0);
# if (devicelist[curnumberofdevices].nrofminors == 0) return -EIO;
# /* Code to initialize devicelist[].rw and .ioctrl */
# curnumberofdevices++;
# return OK;
# }
Roger
--
If the opposite of "pro" is "con", what is the opposite of "progress"?
(stolen from kadokev@iitvax ==? technews@iitmax.iit.edu)
EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
------------------------------
From: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Subject: Linux source code reductions necessary or not?
Date: 13 Mar 92 10:40:46 GMT
Reply-To: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Hi everyone,
Let's recapitulate a little software engineering:
Sourcecode costs money to maintain. In the case of Linux we are all
investing our time (= money) in this. The costs can be expressed
in a formula like:
hardness * size
costs = C * ---------------
quality
Where
C is a constant factor,
hardness is large for sytem programming, low for trivial applications,
size is the size of the sourcecode in lines.
and quality is a measure of the quality of the programming.
In the case of Linux, size is still quite modest (13000 lines), hardness is
high, we are dealing with an OS, and quality is high (Good programming Linus!).
To reduce maintaining costs, you can influence the two parameters in this
equation: the size and the quality. The quality is a very hard parameter
to influence, except for that you should attempt to keep it as high as
possible. However the size parameter is easily influencable in some cases:
for instance, block_read () and block_write () are almost completely identical,
however they are separate routines. If they are merged, the complexity of the
code will increase slightly, (decreasing quality a little), but the size
of the source code will decrease significantly (on this section of the code).
That the maintaining costs of such "identical" routines are really higher
than those for smaller routines, can be demonstrated with an example:
In block_write () some local variables are declared as:
unsigned int block = filp->f_pos >> BLOCK_SIZE_BITS;
unsigned int offset = filp->f_pos & (BLOCK_SIZE-1);
unsigned int chars;
unsigned int size;
and in block_read () as:
int block = filp->f_pos >> BLOCK_SIZE_BITS;
int offset = filp->f_pos & (BLOCK_SIZE-1);
int chars;
int size;
I suspect that this is not what was intended, and someone corrected the
block_write case, but not the block_read . Similar pieces of code
can be found for reading/writing of character devices.
I propose to merge these very similar routines, and reduce the code
size, being careful not to increase complexity too much.
Roger
--
If the opposite of "pro" is "con", what is the opposite of "progress"?
(stolen from kadokev@iitvax ==? technews@iitmax.iit.edu)
EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
------------------------------
From: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Subject: Termcap entry of Linux consoles: lost lines in vi.
Date: 13 Mar 92 10:38:06 GMT
Reply-To: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Hi everyone,
The the termcap entry for the Linux consoles includes the "am" attribute.
This is incorrect and will result in lines lost while using vi, especially
when you page through a file using the j or downarrow key.
The fix is to delete a
:am
from about the second line in the termcap entry of the console you want to
use. (You can fix them all if you want to.....)
Roger
--
If the opposite of "pro" is "con", what is the opposite of "progress"?
(stolen from kadokev@iitvax ==? technews@iitmax.iit.edu)
EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
------------------------------
From: eonu24@castle.ed.ac.uk (I Reid)
Subject: Documentation: an offer/an idea
Date: 13 Mar 92 03:34:52 GMT
I've decided to stick my neck on the line in the hope that I'm not about to
reveal myself as completely stupid :-) It is a simple fact but true that I
don't find the linux documentation particularly clear i.e. it assumes a
reasonable degree of unix sysadmin knowledge (amongst other things). I have
decided that rather than just moaning about things I will make a public offer
to collect information useful to absolute beginners and create an "idiot's
guide" to linux which I would hope could be made available with the standard
documents/files. To this end, I would welcome any information that anyone cares
to send me about the following topics (or any others you think relevant)
1. Basic installation (what's needed, what to do, basics of disk partitioning
etc)
2. Configuring to your own personal needs (Modem on Com3, national keyboards
etc)
3. Booting entirely from hard disk (shoelace or otherwise)
4. Common problems
I don't intend this as an FAQ, just a beginners reference with some usefull
info to get people started and out of trouble.
Is this a daft idea?
Iain
p.s. My biggest tips for Linux are 1. Backup a working version of your setup
before fiddling and 2. Keep a boot and root floppy handy 'cos armed with that
and mount /dev/hd(a)n /user you can recover from most things!
------------------------------
From: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Subject: Writing to kmem allowable? includes patch.
Date: 13 Mar 92 10:28:33 GMT
Reply-To: wolff@neuron.et.tudelft.nl (Rogier Wolff)
Hi everyone,
Some people seem to think that writing to kmem should be prohibited.
I don't think that this is something that should restricted by the kernel.
If you don't like people writing to kmem, set the access rights accordingly.
If you are afraid that root will still be able to write to kmem, then
you should be aware that root isn't called root for nothing: it is the
root of all problems! :-) . But seriously, root can mess up your system
anyway, why not allow writing to /dev/kmem by whoever wants to, and is allowd
according to normal unix file permissions.
I don't see immediate need for writing to kmem, but it should certainly
be implemented, especially since it is only two lines (-:
---- linux/fs/char_dev.c: ----
55c55,56
< /* Writing to kmem, by R.E. Wolff */
< *(char *)i = get_fs_byte (buf++);
---
> return (-EIO);
Ok, many words for a two line patch, just because I thought there may
have been people who thought that writing to kmem was bad. If there are,
I hope I have convinced you, and should you have questions, feel free
to ask.
Roger
--
If the opposite of "pro" is "con", what is the opposite of "progress"?
(stolen from kadokev@iitvax ==? technews@iitmax.iit.edu)
EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
------------------------------
From: michael@gandalf.informatik.rwth-aachen.de (Michael Haardt)
Subject: Re: Linux File System Document Revision 1.0
Date: 12 Mar 92 20:04:33 GMT
Reply-To: u31b3hs@messua.informatik.rwth-aachen.de (Michael Haardt)
From article <4591@mccuts.uts.mcc.ac.uk>, by zlsiial@uts.mcc.ac.uk (A. V. Le Blanc):
> I was involved in the discussion which produced this document,
> and I wish to bring up in this forum a topic which I discussed
> there.
What is the intended purpose of this document? I could think of a few:
- A guide for people how to install Linux
- A guide for people who write/port software for Linux (make install ...)
- A hopefully optimal filesystem structure
- A document about the well-known parts of the historical grown UNIX filesystem
I really don't know. I once thought about a major structure change,
because I never liked /etc and /usr/etc, or things like /usr/lib/tmac.
There are a few ways how bigger software packets like news or other
things could be installed, and the usual way is putting the manual pages
to /usr/man or /usr/local/man, the user commands to /usr/bin or
/usr/local/bin and the rest, if any, to a special directory, often
/usr/whoknows. Putting the user directories in /home is a change I
really appreciate.
> Before the flames begin to sear, let me say that I think this is
> a relatively small point, and that the rest of the document provides
> for a clean, intelligible system which should not be too alien to
> any experienced Unix user, and yet which should be easily grasped
> by Unix novices.
Yes, it is the familar structure.
Some people see Linux as a free POSIX/SYS V kernel, and that's all. I
think it is similar to MINIX in the way that you are free to experiment
with new ideas. So, what would you think of a new structure? One thing
I would like to find in it would be a relation between the filesystem
and the runlevel, another would be a better way to install bigger
software.
Any ideas? Would you appreciate a change or are you glad with the
existing structure? What do you like in it, what don't you like?
Michael
------------------------------
** 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-Activists-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and alt.os.linux) via:
Internet: Linux-Activists@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
tupac-amaru.informatik.rwth-aachen.de pub/msdos/replace
The current version of Linux is 0.12, released on Jan 14, 1992
End of Linux-Activists Digest
******************************
Reference in New Issue View Git Blame Copy Permalink