782 lines
28 KiB
Plaintext
782 lines
28 KiB
Plaintext
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: Tue, 6 Sep 94 14:13:09 EDT
|
|
Subject: Linux-Development Digest #130
|
|
|
|
Linux-Development Digest #130, Volume #2 Tue, 6 Sep 94 14:13:09 EDT
|
|
|
|
Contents:
|
|
Re: Alpha Linux (Anton Ertl)
|
|
Re: IDE Performance enhancement (Mark Lord)
|
|
Re: hdparm.c and/or new fast-IDE won't work now! (Mark Lord)
|
|
Re: BUG/MISFEATURE: umsdos File system (Jacques Gelinas)
|
|
clnttcp_create: RPC: Program not registered (Mark Fernyhough)
|
|
Re: Linux console to SCO comp. prob (Stephen Harris)
|
|
Re: Kernel change summary 1.1.45 -> 1.1.46 (Brad Midgley)
|
|
Re: clnttcp_create: RPC: Program not registered (Mitchum DSouza)
|
|
help SCSI aha1542 broken since 1.1.36 now in 1.1.49 (BARRY TITMARSH)
|
|
Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (Robert Sanders)
|
|
Re: IDE Hard Drives w/ over 1024 cylinders (Patrick J. LoPresti)
|
|
Novell routing between IPX/TCPIP? (Bob Kaehms)
|
|
Re: IDE Performance enhancement (Davor Jadrijevic)
|
|
Re: Alpha Linux (Peter Holzer)
|
|
Re: Linux - my first impressions (Joern Rennecke)
|
|
Re: Alpha Linux (Albert D. Cahalan)
|
|
Americans vs. Europeans (was Re: Unicode...) (Richard L. Goerwitz)
|
|
Re: Kernel change summary 1.1.45 -> 1.1.46 (John McClary Prevost)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
|
|
Subject: Re: Alpha Linux
|
|
Date: 6 Sep 1994 14:21:25 GMT
|
|
|
|
In article <AMBRISKO.94Aug26104834@tasha.kpc.com>, ambrisko@kpc.com (Douglas Ambrisko) writes:
|
|
|> The biggest task with the
|
|
|> Alpha is making everything 64 bit clean and this will apply to the EISA
|
|
|> drivers.
|
|
|
|
Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
|
|
that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
|
|
|
|
- anton
|
|
--
|
|
M. Anton Ertl Some things have to be seen to be believed
|
|
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
|
|
|
|
------------------------------
|
|
|
|
From: mlord@bnr.ca (Mark Lord)
|
|
Subject: Re: IDE Performance enhancement
|
|
Date: 6 Sep 1994 14:23:38 GMT
|
|
|
|
In article <34fu76$ept@library.erc.clarkson.edu> deuelpm@craft.camp.clarkson.edu writes:
|
|
>
|
|
>iozone, while not useful for anthing else, would be perfect for this kind
|
|
>of empirical testing, rather than kernel compilation.
|
|
|
|
IOZONE is very sensitive to the fragmentation of the filesystem on which
|
|
it is used.
|
|
|
|
To get meaningful results, run it on a newly created empty filesystem.
|
|
|
|
On my system, multiple-sector-mode increases IO throughput by about 10%
|
|
with 1.1.49.
|
|
--
|
|
mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
|
|
|
|
------------------------------
|
|
|
|
From: mlord@bnr.ca (Mark Lord)
|
|
Subject: Re: hdparm.c and/or new fast-IDE won't work now!
|
|
Date: 6 Sep 1994 14:29:36 GMT
|
|
|
|
In article <CvpCwB.86G@cs.dal.ca> reynolds@ug.cs.dal.ca writes:
|
|
>
|
|
>I'm having a problem with hdparm as well. I invoke hdparm -m16 /dev/hda,
|
|
>and I get this message:
|
|
>/dev/hda:
|
|
> setting mult-count to 16
|
|
> multcount = 16
|
|
>
|
|
>But when I read /var/adm/messages, I came across this:
|
|
>
|
|
>Sep 6 06:53:05 reynolds kernel: hda: enabled 16-sector multiple mode
|
|
>Sep 6 06:53:05 reynolds kernel: hda: multwrite_intr: status = 0xd0
|
|
>Sep 6 06:53:05 reynolds last message repeated 7 times
|
|
>Sep 6 06:53:05 reynolds kernel: hda: reset multiple mode to 0
|
|
>
|
|
>I quite sure that my system can do 16-sector multiple mode, because I've had
|
|
>great success with similar shareware programs for Messy-DOS. The hard drive
|
|
>subsystem is a Conner CP3044 IDE drive, hooked up to a generic 16 bit
|
|
>Super I/O card. Any suggestions would be appreciated. (-:
|
|
|
|
As noted in the documentation, some CONNER drives have problems.
|
|
|
|
Try it with a smaller setting, such as: hdparm -m8 /dev/hda
|
|
Also, try with irq-unmasking off (default: hdparm -u0 -m8 /dev/hda
|
|
|
|
--
|
|
mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
|
|
|
|
------------------------------
|
|
|
|
From: jack@solucorp.qc.ca (Jacques Gelinas)
|
|
Subject: Re: BUG/MISFEATURE: umsdos File system
|
|
Date: Tue, 6 Sep 94 13:39:30 GMT
|
|
|
|
davison@bruce.cs.monash.edu.au (Andrew Davison) writes:
|
|
|
|
|
|
>Don't know whether anyone else has picked this one up...
|
|
|
|
>The umsdos file system uses a file --linux.--- to store the non-fat file
|
|
>information in. This file is invisible to the user, but apparently not to
|
|
>the file system. If you try to remove a directory on a umsdos partition it
|
|
>balks because the directory is not empty (---linux.--- does not match the *
|
|
>wildcard).
|
|
|
|
This case is managed properly. When a rmdir is done, the directory
|
|
is probe for emptyness and --linux-.--- is properly checked for. There are
|
|
different things that may cause this.
|
|
|
|
1-A file was added with DOS and the directory was not "umssync'ed".
|
|
This means that umsdos is not aware of the added file and. Apply
|
|
umssync as root and you will see those "hidden" file appear.
|
|
|
|
2-One weakness of umsdos is the way it manage hard links. The following
|
|
script will always fail (rmdir ...).
|
|
|
|
mkdir /tmp/a
|
|
mkdir /tmp/b
|
|
echo hello >/tmp/a/file
|
|
ln /tmp/a/file /tmp/b/file
|
|
rm /tmp/a/file
|
|
rmdir /tmp/a
|
|
|
|
Even if /tmp/a is logically empty, a hidden file is still there. Umsdos
|
|
implement hard links as "symlinks" to a hidden file in the original
|
|
directory where the first link was created. The solution to this will
|
|
be to move all hardlinks's hidden file to a special directory /.links.
|
|
This is causing another problem with opened file so it is not done
|
|
now.
|
|
|
|
|
|
--
|
|
|
|
========================================================
|
|
Jacques Gelinas (jacques@solucorp.qc.ca)
|
|
Maintainer of US4BINR jacques@us4binr.login.qc.ca
|
|
|
|
------------------------------
|
|
|
|
From: fernym@pc64.maths.bris.ac.uk (Mark Fernyhough)
|
|
Subject: clnttcp_create: RPC: Program not registered
|
|
Reply-To: Mark.Fernyhough@bristol.ac.uk
|
|
Date: Tue, 6 Sep 1994 14:58:19 GMT
|
|
|
|
After installing libc-4.6.7 i started getting a few problems. First one
|
|
was that the location of utmp changed which was ok to fix, but the second
|
|
was the message:-
|
|
|
|
clnttcp_create: RPC: Program not registered
|
|
|
|
This occured when logging in:-
|
|
|
|
Password:
|
|
Last login: Mon Sep 5 17:06:29 on tty1
|
|
clnttcp_create: RPC: Program not registered <-------------
|
|
Linux 1.1.49. (Posix).
|
|
You have mail.
|
|
|
|
and also when when untarring a file:
|
|
|
|
pc64:~/net> tar xvzf net-tools-1.1.46.tar.gz
|
|
COPYING
|
|
Configure.sh
|
|
Install.sh
|
|
Makefile
|
|
README
|
|
README.hostname
|
|
arp
|
|
clnttcp_create: RPC: Program not registered <-------------
|
|
arp.c
|
|
|
|
Does anyone now how to fix this? Do i have to recompile binaries or do i have
|
|
to redo the /etc/rpc file with a new entry..........?
|
|
|
|
Thanks in advance.
|
|
|
|
Mark Fernyhough
|
|
|
|
------------------------------
|
|
|
|
From: hsw1@papa.attmail.com (Stephen Harris)
|
|
Subject: Re: Linux console to SCO comp. prob
|
|
Date: Tue, 6 Sep 1994 12:57:07 GMT
|
|
|
|
Keith Smith (keith@ksmith.com) wrote:
|
|
: Oh vomit. The Fkey sequences under linux really suck. They would be
|
|
: GREAT if they followed a contiguous pattern, but they don't do that. I
|
|
: don't care what DEC did. A suggestion would be something like:
|
|
|
|
If you don't like them, then build your own keymap file and termcap entry.
|
|
|
|
The point is that programs can't make assumptions about keyboard maps.
|
|
That was the reason for termcap and terminfo in the first place!
|
|
|
|
: 'Splain where F22 is on a VT100 will ya?
|
|
|
|
And explain where it is on a PC keyboard? I'm damn sure there isn't any
|
|
key above F12 on my keyboard.
|
|
|
|
: The WY-50 uses a CTRL-A leadin with characters from the ASCII chart
|
|
: starting with '@' == 1 and work their way up the ASCII chart IN ORDER,
|
|
: following the character with a CR.
|
|
|
|
Isn't this the same keyboard where LEFT-ARROW produces the same code as
|
|
BACKSPACE? And where DOWN-ARROW produces a ^M
|
|
|
|
*Not* my favourite keyboard! IMPOSSIBLE to tell whether the backspace or
|
|
left arrow was pressed. And they sure are used for different purposes!
|
|
(stty erase '^H' anyone?)
|
|
|
|
: I have _NEVER_ seen a consistant DEC VT Function key keymap, but you can
|
|
|
|
Strange. VT220, VT320, VT420, Wyse85, Wyse99GT, MS-Kermit all produce the
|
|
same keycodes for F5->F20 (using Shift on MS-Kermit to get F11-F20).
|
|
Err, also Liberty and Altos5.
|
|
|
|
: So if you wanna emulate the "Most common" sequences you'd best pick the
|
|
: Wyse keyboard sequences.
|
|
|
|
Still disagree. The most common terminal emulation that I have seen is that of
|
|
a DEC VT. But this is besides the whole point of the argument.
|
|
|
|
1) Linux keyboard is reprogrammable
|
|
2) Software with keyboard sequence limits is severly broken.
|
|
--
|
|
|
|
rgds
|
|
Stephen
|
|
|
|
------------------------------
|
|
|
|
From: bmidgley@lal.cs.utah.edu (Brad Midgley)
|
|
Subject: Re: Kernel change summary 1.1.45 -> 1.1.46
|
|
Date: 6 Sep 1994 14:18:10 GMT
|
|
|
|
In article <VISIGOTH.94Sep6041620@olivier.dementia.org>,
|
|
John McClary Prevost <visigoth@olivier.dementia.org> wrote:
|
|
|
|
[multi-user mode changing of append-only/imutable bits]
|
|
|
|
>Hmm. Doesn't this decrease the usefulness of the append-only and
|
|
>immutable bits? As I understood it, the rational for adding these
|
|
>attributes was to make it harder for would-be system crackers to do
|
|
>serious damage or remove traces of their work. (i.e., they break in,
|
|
>hack root, try to remove entries from /var/adm/syslog, and discover
|
|
>that they have to be in single user mode to do anything except append
|
|
>to it.)
|
|
|
|
For this purpose, the raw device must also be immutable. But what
|
|
about mknod? How would mknod know which created-devices should be
|
|
immutable? a root break-in could do anything he wanted to the file
|
|
system with access a writable raw device (albeit difficult).
|
|
|
|
Disallowing mknod exept in single-user mode would be overkill.
|
|
|
|
Brad
|
|
--
|
|
|
|
|
|
Brad
|
|
|
|
------------------------------
|
|
|
|
From: Mitchum.DSouza@mrc-apu.cam.ac.uk (Mitchum DSouza)
|
|
Subject: Re: clnttcp_create: RPC: Program not registered
|
|
Date: 6 Sep 1994 15:18:25 GMT
|
|
|
|
In article <Cvpqx7.Eyz@info.bris.ac.uk>, fernym@pc64.maths.bris.ac.uk (Mark
|
|
Fernyhough) writes:
|
|
|> After installing libc-4.6.7 i started getting a few problems. First one
|
|
|> was that the location of utmp changed which was ok to fix, but the second
|
|
|> was the message:-
|
|
|>
|
|
|> clnttcp_create: RPC: Program not registered
|
|
|>
|
|
|> This occured when logging in:-
|
|
|>
|
|
|> Password:
|
|
|> Last login: Mon Sep 5 17:06:29 on tty1
|
|
|> clnttcp_create: RPC: Program not registered <-------------
|
|
|> Linux 1.1.49. (Posix).
|
|
|> You have mail.
|
|
|>
|
|
|> and also when when untarring a file:
|
|
|>
|
|
|> pc64:~/net> tar xvzf net-tools-1.1.46.tar.gz
|
|
|> COPYING
|
|
|> Configure.sh
|
|
|> Install.sh
|
|
|> Makefile
|
|
|> README
|
|
|> README.hostname
|
|
|> arp
|
|
|> clnttcp_create: RPC: Program not registered <-------------
|
|
|> arp.c
|
|
|>
|
|
|> Does anyone now how to fix this? Do i have to recompile binaries or do i
|
|
|> have
|
|
|> to redo the /etc/rpc file with a new entry..........?
|
|
|
|
Hmmm very interesting...
|
|
|
|
First before people start asking, libc-4.6.7 is not for public use yet, so
|
|
expect problem (perhaps) like these.
|
|
|
|
What rpc services do you use ?? NIS/YP, NYS, NFS, AMD ? Have you changed
|
|
anything recently ??
|
|
|
|
One of the major changes is that the res* and inet* stuff from bsd4.4/bind493b9
|
|
have been integrated with our libc.
|
|
|
|
Mitch
|
|
|
|
------------------------------
|
|
|
|
Date: Tue, 6 Sep 1994 13:12:08 EST
|
|
From: BARRY TITMARSH <BTITMARS@ESOC.BITNET>
|
|
Crossposted-To: comp.os.linux.help
|
|
Subject: help SCSI aha1542 broken since 1.1.36 now in 1.1.49
|
|
|
|
So please. Who is working on scsi aha1542B/C code now..
|
|
I have a broken aha1542 since 1.1.36 and still no fix.
|
|
please mail me if you have info on who is the current maintainer of
|
|
scsi for aha1542
|
|
thnaks.
|
|
see my other postings about scsi bug in 1.1.37--->>--1.1.49
|
|
thnaks.
|
|
|
|
------------------------------
|
|
|
|
From: rsanders@mindspring.com (Robert Sanders)
|
|
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
|
|
Date: 06 Sep 1994 15:20:13 GMT
|
|
|
|
On 6 Sep 1994 00:09:34 -0400, barr@pop.psu.edu (David Barr) said:
|
|
|
|
> Huh? A cache is only good for speed-up purposes. A cache does you no
|
|
> good if you have two incompatible libraries around of the same name
|
|
> that you need simultaneous access to. (Oh, like say X11R5 libX11.so and
|
|
> X11R6 libX11.so) In fact a cache needlessly randomizes and obscures
|
|
> the process. Having compile-time library paths (and filenames) is in
|
|
> no way "binary bloat".
|
|
|
|
But now you're missing the point; Linux shared libraries have the
|
|
concept of major revisions for incompatible changes. You wouldn't
|
|
havbe two libX11.so files lying around. You'd have libX11.so.3 (a
|
|
symlink to libX11.so.3.1.0 or something) and libX11.so.4 (a symlink to
|
|
libX11.so.4.something). ldconfig sets up the symlinks, of course.
|
|
X11R6 binaries would load libX11.so.4 and X11R5 binaries would load
|
|
libX11.so.3.
|
|
|
|
For example:
|
|
|
|
$ ldd /usr/bin/X11/xv
|
|
libX11.so.3 (DLL Jump 3.1) => /usr/X386/lib/libX11.so.3.1.0
|
|
libgr.so.1 (DLL Jump 1.3) => /usr/lib/libgr.so.1.3
|
|
libm.so.4 (DLL Jump 4.5pl21) => /lib/libm.so.4.5.26
|
|
libc.so.4 (DLL Jump 4.5pl21) => /lib/libc.so.4.5.26
|
|
|
|
The filename on the left is the compile-time library name (note the
|
|
trailing major revision number), the parenthesized expression is the
|
|
major&minor revision it was compiled against, and the filename on the
|
|
right is the library it currently resolves to.
|
|
|
|
I'm not saying storing library paths in the executable isn't useful,
|
|
but it seems to me that explicit versioning like Linux does is
|
|
flexible and powerful for any non-synthetic situations. I don't have
|
|
any trouble keeping two (or more) incompatible libwhatever.so
|
|
libraries around. In fact, I can keep them in the same place.
|
|
|
|
-- Robert
|
|
|
|
------------------------------
|
|
|
|
From: patl@lcs.mit.edu (Patrick J. LoPresti)
|
|
Subject: Re: IDE Hard Drives w/ over 1024 cylinders
|
|
Date: 06 Sep 1994 15:22:29 GMT
|
|
|
|
>>>>> Daniel Quinlan <quinlan@freya.yggdrasil.com> writes:
|
|
|
|
> Ack! This isn't needed any more. Linux kernel versions after
|
|
> 1.1.40 (or thereabouts) support EIDE drives directly.
|
|
|
|
1.1.37, I believe.
|
|
|
|
> Yggdrasil's Fall revision includes that support.
|
|
|
|
Cool. At this point, though, I think it is the only distribution
|
|
which does. Until more do, it is probably worth mentioning the hack,
|
|
but with a disclaimer that it is unnecessary if you use a current
|
|
kernel.
|
|
|
|
- Pat
|
|
|
|
------------------------------
|
|
|
|
From: cames@well.sf.ca.us (Bob Kaehms)
|
|
Subject: Novell routing between IPX/TCPIP?
|
|
Date: 6 Sep 1994 15:33:06 GMT
|
|
|
|
|
|
(the way tin's acting, I may have asked this a while back, but since
|
|
I didn't hear any replies....)
|
|
|
|
Does anyone have any ideas on how I could turn Linux into a router for
|
|
both TCPIP and IPX? what would it take to get IPX routing available on
|
|
Linux? Buy-in from Novell? Anyone familar enough with IPX to know whether
|
|
or not this is doable without Novell?
|
|
|
|
Thanks for any pointers...
|
|
|
|
-bob kaehms
|
|
|
|
------------------------------
|
|
|
|
From: davj@ds5000.irb.hr (Davor Jadrijevic)
|
|
Subject: Re: IDE Performance enhancement
|
|
Date: 6 Sep 1994 15:32:42 GMT
|
|
|
|
Patrick Doyle (wdoyle@hilbert.coe.northeastern.edu) wrote:
|
|
: They are included in later revision kernels (I'm not too sure when
|
|
: they first appeared). They have to be specifically enabled, however,
|
|
: using the "hdparm" program.
|
|
|
|
Yes, I did hdparm on 1.1.49 (and the same (de)performance was observed
|
|
from the times around 1.0.x kernels). I test it by cat bigfile > /dev/null
|
|
and ls -lR > /dev/null, to produce lots of disk activity (more than 8MB RAM
|
|
can take). When it comes into stationary stage, I timed cat+ls performance
|
|
and saw -5% on Conner 240M with mmode 16. mkfs speed isn't important to me.
|
|
|
|
d.
|
|
--
|
|
<davor%emard.uucp@ds5000.irb.hr>, <davj@ds5000.irb.hr>
|
|
================ Davor Jadrijevic ====================
|
|
|
|
------------------------------
|
|
|
|
From: hp@vmars.tuwien.ac.at (Peter Holzer)
|
|
Subject: Re: Alpha Linux
|
|
Date: 6 Sep 1994 15:40:03 GMT
|
|
|
|
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
|
|
|
|
>In article <AMBRISKO.94Aug26104834@tasha.kpc.com>, ambrisko@kpc.com (Douglas Ambrisko) writes:
|
|
>|> The biggest task with the
|
|
>|> Alpha is making everything 64 bit clean and this will apply to the EISA
|
|
>|> drivers.
|
|
|
|
>Only if Linux on the Alpha will be a 64-bit-OS.
|
|
|
|
I sure hope it will be. Who wants a 32 bit OS on an Alpha?
|
|
|
|
>If it will be, I hope
|
|
>that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
|
|
|
|
Then you have to drop either the 16 bit or the 32 bit int type. Both
|
|
options may make some people unhappy. The 32 bit int is a reasonable
|
|
compromise. It also breaks all those programs which assume that a
|
|
pointer and an int are just the same thing, which is a good thing IMHO.
|
|
|
|
hp
|
|
--
|
|
_ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems
|
|
|_|_) |------------------------------------------------------------------------
|
|
| | | It's not what we don't know that gets us into trouble, it's
|
|
__/ | what we know that ain't so. -- Will Rogers
|
|
|
|
------------------------------
|
|
|
|
From: amylaar@cs.tu-berlin.de (Joern Rennecke)
|
|
Subject: Re: Linux - my first impressions
|
|
Date: 6 Sep 1994 17:26:24 GMT
|
|
|
|
kjb@cs.vu.nl (Kees J. Bot) writes:
|
|
|
|
>rob@pe1chl.ampr.org (Rob Janssen) writes:
|
|
>>
|
|
>>In <CvK7qx.83I@cs.vu.nl> kjb@cs.vu.nl (Kees J. Bot) writes:
|
|
>>
|
|
>>>rob@pe1chl.ampr.org (Rob Janssen) writes:
|
|
>>
|
|
>>>>In <CvI5oG.1n0@cs.vu.nl> kjb@cs.vu.nl (Kees J. Bot) writes:
|
|
...
|
|
>>>>>The LILO method is rather crude.
|
|
>>
|
|
>>>>I don't think so...
|
|
>>
|
|
>>>>- LILO does not require the boot image to be on contiguous sectors
|
|
>>
|
|
>>>No requirement of any other loader I know.
|
|
>>
|
|
>>Have a look at SYS V systems... They use a separate filesystem for
|
|
>>the bootimages where files always use contiguous blocks.
|
|
|
|
>Brrr. I'd rather not look. I'd rather critize smaller issues of decent
|
|
>operating systems.
|
|
|
|
>>>>- LILO can boot many different kernels and also other operating systems
|
|
>>
|
|
>>>Many different kernels *if* all of them have been mapped. They must be
|
|
>>>carefully mapped whenever a new kernel is installed. That's what I mean
|
|
>>>with crude.
|
|
>>
|
|
>>No, this is done only once when configuring LILO. From then on, all
|
|
>>kernels will be mapped simply by running the installer.
|
|
|
|
>Precisely, they must be carefully mapped by running the installer each
|
|
>time a new kernel is made. (I never supposed one needed to reconfigure
|
|
>the whole lot over and over.)
|
|
|
|
...
|
|
>>>>I think it is a good program, and running its installer after building
|
|
>>>>the kernel is not a problem at all. It is even done in the same
|
|
>>>>"make zlilo" command.
|
|
>>
|
|
>>>Inflexible.
|
|
>>>I like to hack code on one system, copy the resulting kernel image to
|
|
>>>another system with a simple 'rcp' command, and test the new kernel on
|
|
>>>this other system. Both systems are running Minix-386vm, with a
|
|
>>>bootstrap system written by myself that understands Minix filesystems.
|
|
>>
|
|
>>That will really shine on an ext2 partition!
|
|
|
|
>Minix-386vm doesn't have ext2. If so then the boot program would be
|
|
>extended to support it. It is not that much work to just be able to
|
|
>read a file system.
|
|
|
|
I'm still happily using the xiafs filesystem because it has proven to
|
|
be more robust. Scrapping all my files for such a minor bootstrap feature
|
|
is no option for me.
|
|
|
|
>>No, I still think the LILO method is a good idea.
|
|
|
|
>Advantage: No FS code.
|
|
>Disadvantages: Very careful installation of a new kernel. One can only
|
|
>choose from a limited set of kernels. (Which is usually enough, of
|
|
>course.)
|
|
|
|
>Let me describe my bootstrap system, the "Minix Boot Monitor", so that
|
|
>you can compare its features with LILO yourself.
|
|
|
|
>A bootable Minix file system contains a bootstrap in the first sector of
|
|
>the 1k boot block. This bootstrap loads and starts the program /boot
|
|
>using disk addresses patched into its code by the installboot program.
|
|
|
|
>/boot (let's call it "the monitor") reads the second sector of the boot
|
|
>block, the so called "parameters sector" to configure itself. (There
|
|
>are no config files whatsoever, it is all in this parameters sector.)
|
|
|
|
>The monitor interprets a shell like language that has variables, simple
|
|
>functions, menu items, and commands like 'boot', 'delay', 'ls', etc.
|
|
>It can read commands from the keyboard, but normally begins by executing
|
|
>the function 'main'. Main by default runs 'menu'. The menu by default
|
|
>shows one choice: "Start Minix". This "choice" runs the command 'boot'
|
|
>with no arguments.
|
|
|
|
>The boot command selects the newest kernel image from the directory
|
|
>/minix, loads and starts it bringing up Minix. (You know, Minix, "the
|
|
>early Linux development system." :-) )
|
|
|
|
>If I wanted to run an old kernel I would hit ESC to get to the monitor
|
|
>prompt and type:
|
|
|
|
> >ls /minix (The > is the monitor prompt)
|
|
> /minix/1.6.25.1r178 (Blame 'uname -rv' for the names)
|
|
> /minix/1.6.25.1r188
|
|
> >image = /minix/1.6.25.1r178
|
|
> >boot
|
|
|
|
>Knowing the filesystem allows for a nice 'ls' command to look around on
|
|
>the boot device.
|
|
|
|
>To configure my system at home I have typed:
|
|
|
|
> >rootdev = sd2a (Use /dev/sd2a as the root device,
|
|
> not the default RAM disk)
|
|
|
|
> >main() {trap 2000 boot; menu}
|
|
> (Install a 2 second trap to run the
|
|
> command 'boot', then show the menu)
|
|
|
|
> >minix(=,Minix-386vm) {boot}
|
|
> (Add a menu entry for the '=' key)
|
|
|
|
> >dos(d,MS-DOS) {boot hd1} (A menu entry to boot DOS)
|
|
|
|
> >SERIAL3 = on (Enable /dev/tty03, aka COM4)
|
|
> >DPETH0 = :15: (Ethernet 0 is at IRQ 15 instead of
|
|
> the default)
|
|
> >console = 2A:100:40 (Use BIOS mode 2A for 100x40 text)
|
|
|
|
> >save (Save current settings)
|
|
|
|
>If I turn on my machine I see this:
|
|
|
|
> Minix boot monitor 1.6
|
|
|
|
> Press ESC to enter the monitor
|
|
|
|
> Hit a key as follows:
|
|
|
|
> = Minix-386vm
|
|
> d MS-DOS
|
|
|
|
>I have got two seconds to type 'd' before it starts Minix automatically.
|
|
|
|
>Further notes:
|
|
|
|
>The monitor doesn't know what sd2a is, it simply looks up /dev/sd2a in
|
|
>the file system to find its device number. The device number is handed
|
|
>to the kernel. One more advantage to know what the FS looks like.
|
|
|
|
>Choosing the newest kernel from a directory is another advantage of
|
|
>knowing the FS. The monitor can search directories and look at dates.
|
|
>I can simply throw a newer kernel image into /minix and delete one of
|
|
>the older images.
|
|
|
|
Hmm, what about running the install programm in /etc/rc.d/rc.[0K] ?
|
|
|
|
Joern Rennecke
|
|
|
|
------------------------------
|
|
|
|
From: adc@bach.coe.neu.edu (Albert D. Cahalan)
|
|
Subject: Re: Alpha Linux
|
|
Date: 06 Sep 1994 16:38:15 GMT
|
|
|
|
>|> Alpha is making everything 64 bit clean and this will apply to the EISA
|
|
>|> drivers.
|
|
|
|
>Only if Linux on the Alpha will be a 64-bit-OS.
|
|
|
|
I sure hope it will be. Who wants a 32 bit OS on an Alpha?
|
|
|
|
>If it will be, I hope
|
|
>that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
|
|
|
|
Then you have to drop either the 16 bit or the 32 bit int type. Both
|
|
options may make some people unhappy. The 32 bit int is a reasonable
|
|
compromise. It also breaks all those programs which assume that a
|
|
pointer and an int are just the same thing, which is a good thing IMHO.
|
|
|
|
Why drop one?
|
|
16 bits = short int
|
|
32 bits = int
|
|
64 bits = long
|
|
--
|
|
|
|
Albert Cahalan
|
|
adc@meceng.coe.neu.edu
|
|
|
|
------------------------------
|
|
|
|
From: goer@quads.uchicago.edu (Richard L. Goerwitz)
|
|
Subject: Americans vs. Europeans (was Re: Unicode...)
|
|
Reply-To: goer@midway.uchicago.edu
|
|
Date: Tue, 6 Sep 1994 15:57:19 GMT
|
|
|
|
iialan@iifeak.swan.ac.uk (Alan Cox) writes:
|
|
|
|
>>Finally, do the display drivers and GUIs support multiple wordwrap
|
|
>>directions?
|
|
>
|
|
>X windows does. Its fair to say its not exactly used a lot but X can do it.
|
|
|
|
Thanks for a thoughtful posting. This one part I'm not sure is right.
|
|
X doesn't know anything about text. It's the anciliary libraries that
|
|
take care of that. So the question is what widget sets support non-
|
|
western languages and alternate wordwraps (as well as bidirectional word-
|
|
wrap, which for left-right/right-left languages has established typo-
|
|
graphical conventions). Do you really know of any that do this well?
|
|
|
|
>>Am I babbling nonsense, or am I making sense?
|
|
>
|
|
>You are raising issues that most people don't care about or need, but which
|
|
>I suspect you are right in believing will matter some day.
|
|
|
|
I see what you mean. This is the attitude many Americans take to their
|
|
European counterparts - the thing that so annoys Europeans: The idea
|
|
that scripts or coding schemes other than the ones used here in the US
|
|
are unimportant, or at best left to the locals to worry about.
|
|
|
|
I wonder how many US programmers even today know not to do things like
|
|
use 'a' in place of decimal 97. ANSI C uses setlocale to change the com-
|
|
piler's interpretation of what 'a', etc. mean. Again, I don't pretend
|
|
to be a guru or anything. I just want to emphasize that if Linux is to
|
|
"take off" as a worldwide OS, US programmers involved in its creation
|
|
need to think more globally than they might have been inclined to do in
|
|
the past. Linux doesn't carry the same baggage that other Unixes do, &
|
|
there exists a marvellous opportunity here for globalization.
|
|
|
|
The same remarks applied to US programmers re Europeans, BTW, may be
|
|
applied to Europeans vis-a-vis the rest of the world (i.e. the majority
|
|
of the world - which speaks languages like Urdu, Chinese, Arabic, etc.).
|
|
No fair pointing fingers at Americans, while comitting the same sins
|
|
as us :-).
|
|
|
|
|
|
--
|
|
|
|
-Richard L. Goerwitz goer%midway@uchicago.bitnet
|
|
goer@midway.uchicago.edu rutgers!oddjob!ellis!goer
|
|
|
|
------------------------------
|
|
|
|
From: visigoth@olivier.dementia.org (John McClary Prevost)
|
|
Subject: Re: Kernel change summary 1.1.45 -> 1.1.46
|
|
Date: 6 Sep 1994 17:36:35 GMT
|
|
|
|
Brad Midgley (bmidgley@lal.cs.utah.edu) wrote:
|
|
: In article <VISIGOTH.94Sep6041620@olivier.dementia.org>,
|
|
: John McClary Prevost <visigoth@olivier.dementia.org> wrote:
|
|
|
|
: [multi-user mode changing of append-only/imutable bits]
|
|
|
|
: >Hmm. Doesn't this decrease the usefulness of the append-only and
|
|
: >immutable bits? As I understood it, the rational for adding these
|
|
: >attributes was to make it harder for would-be system crackers to do
|
|
: >serious damage or remove traces of their work. (i.e., they break in,
|
|
: >hack root, try to remove entries from /var/adm/syslog, and discover
|
|
: >that they have to be in single user mode to do anything except append
|
|
: >to it.)
|
|
|
|
: For this purpose, the raw device must also be immutable. But what
|
|
: about mknod? How would mknod know which created-devices should be
|
|
: immutable? a root break-in could do anything he wanted to the file
|
|
: system with access a writable raw device (albeit difficult).
|
|
|
|
: Disallowing mknod exept in single-user mode would be overkill.
|
|
|
|
I think the difficulty is the main idea... No system can be totally
|
|
secure, only very very hard to break into. If a cracker has utilities
|
|
to work with the raw disk and frob the immutable bits, or is able
|
|
to patch up the syslog by hand on the raw device, there's really not
|
|
anything you can do to stop them once they get to root. I suppose
|
|
anyone who's really intent on hacking root and not leaving a trace
|
|
will do this... But they could get burned the first time.
|
|
|
|
In any case, the immutable and read-only aren't all that useful yet,
|
|
except that it's a read-only flag that effects even root, kind of
|
|
an idiot-proof setup. I hope that the idea is expanded upon, though.
|
|
|
|
--
|
|
@-`-,-- John McClary Prevost
|
|
Systems Programmer, CS Facilities, Carnegie Mellon University
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|