Linux v0.95a rootimage uploaded
Jim Winstead Jr.
with the bootimage, you will have to wait for it to be moved to an
accesible directory. (I assume it will be moved over at the same time
as the bootimage.)
A summary of the changes has been included in the file CHANGES-0.95a,
also uploaded, and is also included below. There is also an
INSTALL-0.95a, which I have not posted below since it is largely a
rehash of INSTALL-0.11 and RELNOTES-0.95.
As Linus has said, these files will available in a day or two from
nic.funet.fi, and an announcement will be made when that happens.
They will be available on the other sites shortly after that.
-----------------------------------------------------------------------
CHANGES IN THE LINUX v0.95a ROOT DISKETTE
Jim Winstead Jr. - March 17, 1992
This file mostly contains info about the changes in the root diskette
from Linux v0.95/0.12 to Linux v0.95a.
CHANGES
With the release of Linux v0.95a, the maintenance of the root diskette
has been assumed by Jim Winstead Jr. (jwin...@jarthur.Claremont.EDU).
This means there are a few large changes between the Linux 0.95 and
0.12 root floppies and the Linux 0.95a root floppy. These are
detailed (as much as I remember them) below:
- 'bash' has been replaced with 'ash', the BSD 4.3 /bin/sh. This
freed up nearly 200k on the root floppy. However, there are
some problems with 'ash' that haven't been resolved:
- sometimes the backspace key will not work on a virtual
console. I've found that it usually works on all _but_ one
console, so this is only a minor hinderance.
- 'ash 'supports BSD-style job control, and this has not yet been
adapted to Linux's more POSIXish job control. This means
that 'ash' does not yet support job control, but it's being
worked upon.
- 'tar' and 'compress' are back on the root floppy. 'tar' is
compressed, and both utilities are in /bin.
- 'pfdisk', a disk partitioner, was added to the root floppy.
This makes it (almost) possible to install Linux on a machine
without looking at another OS.
- the file pager 'more' has been added to the floppy. This was
added because of the addition of some documentation files on
the root floppy.
- 'cat' has been added to /bin.
- many utilities have been moved from /usr/bin to /bin, to
conform to the Linux Directory Structure Standard (v1.0).
These utilities are ones that are 'vital to the restoration of
other file systems in the case of a corrupting crash.'
- 'init' and 'update' have been moved to /etc from /bin. This
was done because neither program should be executed from the
command line by any user, including root. (That means don't
put /etc in your PATH!) This has been a matter of some
controversy, but this is how it will stand until the Linux
Standards mailing list/committee decides otherwise.
- tty64, tty65, etc, have been renamed to ttys1, ttys2, etc.
- the directory /INSTALL was added, which contains some
documentation, and three simple shell scripts to make
installing Linux on a hard drive partition easier. These are:
- 'mktree', which makes a directory tree on the specified
mounted device.
- 'mkdev' which creates the standard devices in the dev
directory of the specified mounted device
- 'install' which installs the programs on the root diskette
to the specified mounted device
These programs will normally be called with '<name> /mnt'.
- rootdev is different than the one on v0.95. A couple of days
after the release of 0.95, a program called 'rdev' was posted
to alt.os.linux that duplicated and extended the functionality
of rootdev. This was renamed to rootdev and replaces the old
rootdev.
- agetty was renamed to getty, to be consistent with common Unix
practice.
- an improved fdisk was added that correctly reports extended
partitions, (Thanks to Linus!)
- /dev is complete, or at least more complete than the last few
releases of the root diskette, which always seemed to be a
major complaint. :)
- /etc/issue and /etc/motd have been expanded to be a little
more informative. (Yeah, I know, big deal! :)
- chgrp was removed. You can use chown to get the same effect,
but you just have to specify an owner, too.
Many of these changes were discussed on alt.os.linux, or the Linux
Standards group, so they may look familiar.
If you have questions, problems, or complaints about the root
diskette, either post to alt.os.linux, or send mail to me at
jwin...@jarthur.Claremont.EDU.
If you have questions, problems, or complaints about the boot diskette
or the kernel itself, post to alt.os.linux or send mail to Linus
Torvalds at torv...@cc.helsinki.fi.
Remember, the only stupid questions are the ones you don't ask.
FUTURE CHANGES
I'm already anticipating some changes for the next release, so here's
a sneak preview:
- shared libraries. These are currently in alpha testing, and
will hopefully free up some more room on the root floppy for
more goodies.
- a generic mtools might be added to the root floppy.
- a better fdisk to replace the current fdisk/pfdisk pair. You
won't need to know your drive's geometry for this, and it will
know about Linux extended partitions.
- an improved sh. I'm working on the backspace problem, and
adding job control. I'm also going to look at using the GNU
readline library for input, as long as it doesn't add
substantially to the size of sh.
- init/getty/login may be removed from the root floppy. The
main reason they'll still on there is the backspace problem
with ash.
- improved installation documentation. People have started work
on this already - read alt.os.linux for previews.
- more robust installation scripts. The current ones are quick
and dirty, and work well, but I'd like to add better ones.
- miscellaneous utilities added. I'd really like to add an
editor to the root disk, but I haven't found one small enough.
Any suggestions?
- various other things that I can't remember right now.
Again, mail your questions, comments and suggestions about the root
diskette to me at jwin...@jarthur.Claremont.EDU.
--
Jim Winstead Jr. (CSci '95) | "Catch a fish!"
Harvey Mudd College | -Geddy Lee,
jwin...@jarthur.Claremont.EDU | San Diego Sports Arena
Disclaimer: Mine, not theirs! | January 20, 1992
Kevin Cummings
last night. So, I thought I would list a few comments after booting
it on my system.
My System configuration:
386-DX 25MHz
1.2MB and 1.4MB floppies
70MB and 80MB MFM hard disk drives
4MB ram memory
256K S-EGA (Genoa clone) (NEC 3D monitor)
4 serial ports (COM1-COM4, IRQs 4,3,4,3)
Bus Mouse (IRQ 7, oops, not supported yet B^)
1) The rootimage on tsx-11 was identified as corrupt 5 minutes
after I started downloading it! Sigh. So I created both
a 0.95a BOOT floppy for the 0.95 ROOT disk, and a 0.95a BOOT
floppy for my hard disk file system (also 0.95 root disk).
2) The boot loaded the 8x8 font after not recognizing my video card.
OK, it's an EGA, so my screen is now 80x43. LINUX thinks my
screen is 80x50! And it sets up the TERM variable of my login
shells to con80x50. It also tells my video controller that I
must have 50 line per screen, because 17 lines disappear below
line 43 before the display starts to scroll! Can I give a simple
test to the video people to discern VGA from EGA? It was published
in DDJ a while back when they started the Graphics column.
It involves calling a VGA BIOS interrupt. EGAs (and CGAs, etc)
return the function number, while VGAs return a 0 error code.
Very simple.
2a) I want to add my EGA extended text modes to the setup.c code.
I guess if I am patching code for my own use, I can just add
it at the fall through label where everything else failed.
In order to do more (and send my new code back to Linus for
inclusing into the real source), does anyone know how to detect
a GENOA EGA BIOS? I can find GENOA copyright notices in the EGA
BIOS. Are these notices in the same location in EVERY GENOA
EGA card? Does the SVGA book mention anything about EGA cards?
2b) OK, so I may be buying an "S3" based SVGA card soon (it was going
to be Real Soon Now, but my 70MB disk had a head crash last night,
bad timing, huh?). Is there any "clues" for these new cards?
S3 text modes should still be limited to 16 colors, regardless
of the graphics modes capabilities (with Sierra RAMDACs).
(It was going to be the Diamond Stealth Hi-Color w/1MB, in case
anyone was interested.)
3) So I reset the TERM value, and EXPORT it from BASH. GnuEMACS
still thinks I have 50 lines on my screen. Is it ignoring the
TERM environment variable? Do I have to load a local TERMCAP
environment variable? The shell also still beleives I have 50
lines of text. Is this because my video card seems to beleive
this as well? Do I have to re-set a register on the video card?
4) I cannot run KA9Q or KERMIT from a non-root user. KERMIT says
EPERMS when trying to open the serial port. KA9Q gets in an
infinite loop that neither ^Z nor ^C can abort! How can I log
the user out? Do I need a ps command? How can the user access
the serial port? Do I need to chmod /dev/ttys0?
4a) KA9Q does the same if you try and open a non-existent serial device.
Even as ROOT. Can't get out of it.
Side Comment to new ROOT disk maintainer: Make the serial ports
ttys0, ttys1, ttys2, and ttys3. All other devices are 0 based.
ttysx should be too. I also like the idea of the hard disks
being numbered as hdXY where X is a disk number and Y a partition
number (or letter for SUN compatibility). The same should hold
true for SCSI disks: sdXY. Both hd and sd devices should use the
SAME naming scheme for X and Y. either both numbers, or 1 letter
and one number. If up to 16 partitions are to be allowed, then
X should be a number, and Y a letter to keep the devices as 4
character names. (We won't be supporting more than 10 disk drives
per controller, will we??)
5) Since I'm going to be buying a new disk drive or disk drive/controller
RSN, what are LINUX's restrictions with regard to ESDI, IDE, and SCSI.
I'm looking at 4 possibilities, with budget approval:
a) Find an 80MB HH MFM drive to replace my 70MB FH drive that died.
this will allow me to replace my DOS stuff with minimal changes,
and give me 9-10 more MB for LINUX partitions.
b) Buy a 150MB ESDI drive from a friend, an ESDI controller, and
try to run this along with my current 80MB MFM disk under both
DOS and LINUX. This will be about the same cost as a) after the
new controller, and allows me a new 80MB of disk space.
If I cannot run both drives together, I will still have 150MB
total disk space. DO I NEED TO WRITE AN ESDI DRIVER or is
someone already working on one? This answer might influence
the brand of ESDI controller to buy.
c) Buy a SCSI drive and controller. SCSI is the wave of UNIX,
though SCSI support for LINUX seems limited. I've been
reccomended to buy either a WD or Adaptec controller if I
want to run more than just hard disks from it (like cartridge
tape, or CD-ROM). Is there more SCSI support than just the
Seagate ST-0x controllers? If so, then for what?
d) Buy an IDE drive and bus interface. Same question. Can I
use LINUX with IDE drives? Are there IDE drives I cannot
(yet) use LINUX with?
In all b), c) and d), I'm assuming that I can run two different
disk drive types on two different controllers as long as either
the MFM or IDE controllers can be configured as the "secondary"
disk controller. I have a fried who claims its possible with
an ESDI controller as his primary, and an IDE as his secondary;
under DOS. I assume this will work under LINUX also? Or does
LINUX not yet support any disk controllers at the secondary address?
So basically, what is my best choice for LINUX from the four above?
=================================================================
Kevin J. Cummings Prime Computer Inc.
20 Briarwood Road 500 Old Connecticut Path
Framingham, Mass. Framingham, Mass.
InterNet: cumm...@primerd.Prime.COM
UUCP: uunet!primerd.Prime.COM!cummings
Std. Disclaimer: "Mr. McKittrick, after careful consideration,
I've come to the conclusion that your new
defense system SUCKS..." -- War Games
=================================================================
Charles Hedrick
>What terminal type does KA9Q/LINUX support through TELNET connections.
>I have not had any luck trying to use VT100 as a terminal type.
>Should I be using the same TERMCAP entry on the remote side as is
>available locally in LINUX, even though LINUX doesn't use it B^)?
Here's what I use. It's based on the termcap entry supplied with
Linux, but has removed a few things that don't work (at least in
0.12). It is set up for a color screen, so it gives you a green Emacs
mode line.
linux|linux console:\
:do=\E[B:co#80:li#25:cl=\E[H\E[J:sf=\ED:sb=\EM:\
:le=^H:bs:am:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:\
:ce=\E[K:cd=\E[J:so=\E[42m\E[30m:se=\E[m:us=\E[4m:ue=\E[m:\
:md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:is=\E[1;25r\E[25;1H:\
:ll=\E[1;25r\E[25;1H:dc=\E[P:\
:it#8:ku=\E[A:kd=\E[B:kr=\E[C:kl=\E[D:kb=^H:ti=\E[r\E[H:\
:ho=\E[H:kP=\E[5~:kN=\E[6~:kH=\E[Y:kh=\E[H:kD=\E[3~:kI=\E[2~:\
:k1=\E[[A:k2=\E[[B:k3=\E[[C:k4=\E[[D:k5=\E[[E:k6=\E[[F:\
:k7=\E[[G:k8=\E[[H:k9=\E[[I:k0=\E[[J:K1=\E[[K:K2=\E[[L:\
:pt:sr=\EM:vt#3:xn:\
:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:
Paul Riddle
it justs sit there, on the IBM. Maybe I'm not waiting long enough, I
did get it in binary mode.
Joe
Jim Winstead Jr.
>1) The rootimage on tsx-11 was identified as corrupt 5 minutes
> after I started downloading it! Sigh. So I created both
> a 0.95a BOOT floppy for the 0.95 ROOT disk, and a 0.95a BOOT
> floppy for my hard disk file system (also 0.95 root disk).
If you'd waited about ten minutes more, the problem would have been
corrected... :) In any case, the 0.95a root disk, not corrupted, is
available on tsx-11.mit.edu now. I'm not sure if the one on
nic.funet.fi has been updated yet.
>2) The boot loaded the 8x8 font after not recognizing my video card.
> OK, it's an EGA, so my screen is now 80x43. LINUX thinks my
> screen is 80x50! And it sets up the TERM variable of my login
> shells to con80x50. It also tells my video controller that I
That's something I hadn't considered when I did the 8x8 font - oops.
If someone can send a simple way to tell whether a EGA or VGA card is
in use, it's a trivial change. (For now, change the line that says
'return 80x50' to 'mov al, #0x502b', which will tell the kernel you're
using 80x43. Make sure to create a con80x43 termcap entry!)
>2a) I want to add my EGA extended text modes to the setup.c code.
If the EGA extended modes are handled through int 10, it would be
simple to add the detection routine as if it were a SVGA card. If it
involves selecting different fonts, scan lines, etc, it gets a bit
trickier. (I might look at this eventually for different VGA modes,
but not yet....)
>3) So I reset the TERM value, and EXPORT it from BASH. GnuEMACS
> still thinks I have 50 lines on my screen. Is it ignoring the
> TERM environment variable? Do I have to load a local TERMCAP
> environment variable? The shell also still beleives I have 50
> lines of text. Is this because my video card seems to beleive
> this as well? Do I have to re-set a register on the video card?
When you modify termcap to handle con80x43, you should be able to copy
con80x50 and just change any reference to '50' to a '43'. There's
about four or five things you need to change.
>4) I cannot run KA9Q or KERMIT from a non-root user. KERMIT says
> EPERMS when trying to open the serial port. KA9Q gets in an
> infinite loop that neither ^Z nor ^C can abort! How can I log
> the user out? Do I need a ps command? How can the user access
> the serial port? Do I need to chmod /dev/ttys0?
Make sure the serial devices have read/write permissions set for
everyone. (That'd mean chmod /dev/ttys*.)
>Side Comment to new ROOT disk maintainer: Make the serial ports
> ttys0, ttys1, ttys2, and ttys3. All other devices are 0 based.
Good point, and one I hadn't thought of. I'll make the change for the
next root disk. (Just in case everyone isn't confused enough already!)
> ttysx should be too. I also like the idea of the hard disks
> being numbered as hdXY where X is a disk number and Y a partition
> number (or letter for SUN compatibility). The same should hold
> true for SCSI disks: sdXY. Both hd and sd devices should use the
> SAME naming scheme for X and Y. either both numbers, or 1 letter
> and one number. If up to 16 partitions are to be allowed, then
> X should be a number, and Y a letter to keep the devices as 4
> character names. (We won't be supporting more than 10 disk drives
> per controller, will we??)
The current naming scheme could handle 26 drives and 15 partitions per
drive. Y can be hexidecimal, much as the pty numbers are. (16 if we
made them zero-based....)
> d) Buy an IDE drive and bus interface. Same question. Can I
> use LINUX with IDE drives? Are there IDE drives I cannot
> (yet) use LINUX with?
I run Linux with two IDE drives (a Conner and a Seagate, with a
Seagate controller). It works fine for me, but I'm not mixing drive
types.
Drew Eckhardt
>
>2b) OK, so I may be buying an "S3" based SVGA card soon (it was going
> to be Real Soon Now, but my 70MB disk had a head crash last night,
> bad timing, huh?). Is there any "clues" for these new cards?
> S3 text modes should still be limited to 16 colors, regardless
> of the graphics modes capabilities (with Sierra RAMDACs).
> (It was going to be the Diamond Stealth Hi-Color w/1MB, in case
> anyone was interested.)
>
Something to keep in mind if you are a non-hacker, or won't have enough
disk space to build the Xserver.
The stock X386 driver supports Tseng and
>Side Comment to new ROOT disk maintainer: Make the serial ports
> ttys0, ttys1, ttys2, and ttys3. All other devices are 0 based.
> ttysx should be too. I also like the idea of the hard disks
I agree wholeheartedly with this. My feeling is that Linux should appear
as "standard as possible", with normal names for disks, serial
ports, etc. On most Unix machines, disks are numbered in the form
/dev/{r,}{h,s}d followed by a disk number and then a partition number.
Normally, I've seen disks numbered numerically, partitions with letters,
and it's pretty safe to assume partition c is the whole disk, a root,
g usr, etc.
> being numbered as hdXY where X is a disk number and Y a partition
> number (or letter for SUN compatibility). The same should hold
> true for SCSI disks: sdXY. Both hd and sd devices should use the
> SAME naming scheme for X and Y. either both numbers, or 1 letter
> and one number. If up to 16 partitions are to be allowed, then
> X should be a number, and Y a letter to keep the devices as 4
> character names. (We won't be supporting more than 10 disk drives
> per controller, will we??)
Technically, with SCSI it is possible. There are SCSI controllers that
hang off of a SCSI bus, and make 7 SCSI drives appear as LUN 0-6 of
their ID. You can have 7 of these on one SCSI bus - so that's
49 drives!
>5) Since I'm going to be buying a new disk drive or disk drive/controller
> RSN, what are LINUX's restrictions with regard to ESDI, IDE, and SCSI.
> I'm looking at 4 possibilities, with budget approval:
>
> a) Find an 80MB HH MFM drive to replace my 70MB FH drive that died.
> this will allow me to replace my DOS stuff with minimal changes,
> and give me 9-10 more MB for LINUX partitions.
>
> b) Buy a 150MB ESDI drive from a friend, an ESDI controller, and
> try to run this along with my current 80MB MFM disk under both
> DOS and LINUX. This will be about the same cost as a) after the
> new controller, and allows me a new 80MB of disk space.
> If I cannot run both drives together, I will still have 150MB
> total disk space. DO I NEED TO WRITE AN ESDI DRIVER or is
> someone already working on one? This answer might influence
> the brand of ESDI controller to buy.
Note that ESDI / MFM / RLL / IDE normally all appear to the system
as a WD1003 compatable conroller. This means that they occupy the same
address. You can set one up as a secondary. but right now Linux does
not support this. Hard disk driver hack, anyone?
> c) Buy a SCSI drive and controller. SCSI is the wave of UNIX,
> though SCSI support for LINUX seems limited. I've been
> reccomended to buy either a WD or Adaptec controller if I
> want to run more than just hard disks from it (like cartridge
> tape, or CD-ROM). Is there more SCSI support than just the
> Seagate ST-0x controllers? If so, then for what?
>
This will probably be the way to go, but Right Now (tm), the only
fully supported adapter is the Seagate. However, Dave Gentzel
is in the testing stages with his lowlevel Ultrastor driver, David Darknell
with the lowlevel CSC driver, Tommy Thorn is working on an adaptec,
Michael Johnson on a DTC driver, other people on Future Domain and
Always IN-2000.
SCSI also coexists with MFM / RLL / IDE / ESDI with no problems.
As far as SCSI now, your choice are to wait, or if you have a good
deal on a SCSI disk pick one up and use it with a Seagate ($20)
until you get a "real" SCSI host.
Since the Linux SCSI drivers do not go through BIOS, or any brain-dead
mapping schemes to get the disks to fit within the geometries
allowed by BIOS / DOS, and instead uses that native SCSI as a block
device, you will be able to unplug one host adapter, plug in a different
one, hook the same disk up to it, and use it without reformatting or
anything.
> d) Buy an IDE drive and bus interface. Same question. Can I
> use LINUX with IDE drives? Are there IDE drives I cannot
> (yet) use LINUX with?
Yes and no.
> In all b), c) and d), I'm assuming that I can run two different
> disk drive types on two different controllers as long as either
> the MFM or IDE controllers can be configured as the "secondary"
> disk controller. I have a fried who claims its possible with
> an ESDI controller as his primary, and an IDE as his secondary;
> under DOS. I assume this will work under LINUX also? Or does
> LINUX not yet support any disk controllers at the secondary address?
With SCSI and unmodified sources (other than the SCSI patches), only
SCSI will coexist with any of the others. Otherwise, you'll have to
hack the HD driver to support a primary / secondary controller.
> So basically, what is my best choice for LINUX from the four above?
>
If you want to use your current disk too, I'd say SCSI - but you probably
want to wait for something other than the Seagate (slow, but very cheap),
or Ultrastor / CSC (fast, but not so cheap) drivers.
If you don't care about your current disk, or don't mind hacking
in support for primary / secondary controllers, I'd say whatever
is cheapest.
Kevin Cummings
I have not had any luck trying to use VT100 as a terminal type.
Should I be using the same TERMCAP entry on the remote side as is
available locally in LINUX, even though LINUX doesn't use it B^)?
=================================================================
Humberto Ortiz-Zuazaga
>In article <1992Mar1...@hammer.Prime.COM> cumm...@hammer.Prime.COM (Kevin Cummings) writes:
>>Side Comment to new ROOT disk maintainer: Make the serial ports
>> ttys0, ttys1, ttys2, and ttys3. All other devices are 0 based.
>
>Good point, and one I hadn't thought of. I'll make the change for the
>next root disk. (Just in case everyone isn't confused enough already!)
tty0 is the curent screen, tty1 is the actual first console, hda1 is
the first partition on the first drive, ttys1 _should_be_ the first
serial port.
IMNSHO :-)
--
Humberto Ortiz-Zuazaga INTERNET: zua...@ucunix.san.uc.edu
Dept. of Physiology & Biophysics BITNET: picone@ucbeh
University of Cincinnati CIS: 72301,2303
Jim Winstead Jr.
>In article <1992Mar19.2...@muddcs.claremont.edu> jwin...@jarthur.claremont.edu (Jim Winstead Jr.) writes:
>>In article <1992Mar1...@hammer.Prime.COM> cumm...@hammer.Prime.COM (Kevin Cummings) writes:
>>>Side Comment to new ROOT disk maintainer: Make the serial ports
>>> ttys0, ttys1, ttys2, and ttys3. All other devices are 0 based.
>>
>>Good point, and one I hadn't thought of. I'll make the change for the
>>next root disk. (Just in case everyone isn't confused enough already!)
>
>tty0 is the curent screen, tty1 is the actual first console, hda1 is
>the first partition on the first drive, ttys1 _should_be_ the first
>serial port.
Are you sure tty0 is the current screen? For my /dev, there isn't a
/dev/tty0. There's a /dev/tty, which has major 5, minor 0, but
there's no /dev/tty0. Perhaps /dev/tty[1-8] is wrong, too. :)
The same goes for /dev/hda*. Why are they not zero-based? Seems like
a bit of inconsistency, to me.
On a related note, has anyone given thought to a consistent
floppy-naming scheme? I really don't like the current /dev/PS0,
/dev/at0 stuff.
I was thinking of something along the lines of /dev/fdXY, where X
would represent the drive number (0 = A, 1 = B, etc.) and where Y
would be alphabetic, representing the type of format/drive type.
(i.e. a = 360k on 360k, b = 1.2m in 1.2m, c = 360k in 720k/1.44m)
Does anyone see a problem with this sort of naming scheme?
no, I don't repeat it!
>SCSI disks: sdDP where D = drive [0-7], P = partition [a-z]
> Note: I don't know enough about the SCSI drives
> to know if this is appropriate for them
It's appropriate, although theoretically one can have multiple host adapters,
etc to get over 7 drivers.
True, and multiple LUN's (at least 2) per controller should also be
supported. In fact, I often run SCSI-based systems with multiple
host adapters.
Extended partitions should also, IMHO, be defined with their own letter,
like they were just multiple filesystems in a single partition (as in
SCO Xenix and Unix). The system should of course support using only a
single extended partition with multiple file systems.
"Primary" partition support could very well be dropped as too dos'ian thing.
An operating system should not need to use more than one entry in the
"master" partition table.
So, we end up with at least:
SCSI disks: [r]sdHCLPF where H = host adapter [0-1],
C = controller [0-7],
L = LUN [0-1],
P = partition [0-4] and
F = file system [0-7, for example]
Each disk controller would of course need an own major number, but this
should not be a problem. This is also what SCO Unix does.
Pauli
--
Disclaimer fault - lawyers dumped
Ronald S H Khoo
> I like the idea of having a link from /dev/fd to the
> floppy device I normally use,
Current practice has /dev/fd being a directory or pseudo-directory where
you can open /dev/fd/<number> to get a dup of a filedescriptor, with links
from
/dev/fd/0 -> /dev/stdin
/dev/fd/1 -> /dev/stdout
/dev/fd/2 -> /dev/stderr
It would be nice if you *didn't* use /dev/fd for the floppy disc
so that Linux might be able to follow this convention as and when someone
implements /dev/fd/* :-) Can I suggest /dev/floppy or /dev/fpy instead ?
I do agree with the general principle though. In fact, I do the same thing
myself :-)
--
Ronald Khoo <ron...@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
Symbolic links turn your filesystem from a tree into a bramble bush
Michael K. Johnson
From: da...@ods.com (David Engel)
: Naming the serial ports /dev/tty[a-d] runs into problems if someone
: has more than 9 virtual consoles (is that even possible?).
Probably possible, but not very likely. I have trouble using up the
standard 4. 8 is more than I would ever need. I don't multitask as
well as Linux. :)
-David
What about people who want to run BBS's on theis linux boxes? They
may well want more than that number of serial ports. There are smart
many serial port cards...
just a thought...
michaelkjohnson
john...@stolaf.edu
David Engel
: hed...@dartagnan.rutgers.edu (Charles Hedrick) writes:
:
: > I like the idea of having a link from /dev/fd to the
: > floppy device I normally use,
:
: Current practice has /dev/fd being a directory or pseudo-directory where
: you can open /dev/fd/<number> to get a dup of a filedescriptor, with links
: from
: /dev/fd/0 -> /dev/stdin
: /dev/fd/1 -> /dev/stdout
: /dev/fd/2 -> /dev/stderr
:
: It would be nice if you *didn't* use /dev/fd for the floppy disc
: so that Linux might be able to follow this convention as and when someone
: implements /dev/fd/* :-) Can I suggest /dev/floppy or /dev/fpy instead ?
Let me clear this up before it goes any further. My suggestion was to use
/dev/fdD (ie. /dev/fd0, /dev/fd1) for the floppy drives with default format
and not /dev/fd.
--
David Engel Optical Data Systems, Inc.
da...@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
David Engel
: What about people who want to run BBS's on theis linux boxes? They
: may well want more than that number of serial ports. There are smart
: many serial port cards...
True, but a smart serial card would require a new, major device number
and driver so we might want to use different naming scheme for them.
Britt Park
I have Linux 0.95a running fine on my 386 clone with 4Mb (80Mb IDE,
AMI bios, OPTI chip set). Yesterday I bought 4Mb of RAM to bring my machine
up to 8Mb. The power on memory test OK's the new RAM; MSDOS runs fine; Minix
runs fine, recognizing all the memory. However, Linux gives a kernel panic:
free block list corrupted, or some such. I think it unlikely that the RAM is
at fault since I've switched the new RAM for the original 4Mb and everything
works fine. Is this a known problem? Do I have to reconfigure the kernel?
Any help would be appreciated.
nic...@ttd.teradyne.com
>
> : >Serial ports: ttyX where X = number [a-d]
> : > Note: ttys[1-4] are sometimes used for PTY's
> :
One thing I'd like clarified. Are we so enamored (sp?) with
'tty' that nothing else can be considered? After having worked
a while with ISC's 386 UN*X, I've found I like their nameing
convention: /dev/vt?? for Virtual Terminals, /dev/pt?? for
network psuedo terminals, and /dev/tty?? for real, honest-to-goodness
serial ports. And yes, /dev/tty automagically gets your output
to you, regardless of which device you are actually using.
Admittedly the number of users on a Linux system (at the moment) is
very close to 1. However, someday, that will change, and I'd like
to see a naming convention that lends one to easily see how someone
is accessing the machine.
Just a thought.
(Please be gentle, my asbestos suit was confiscated by OSHA)
Richard D. Nichols
Teradyne Inc., Telecommunications Division
Phone: (708) 940-9000
Email: nic...@ttd.teradyne.com
Risto Kankkunen
>john...@stolaf.edu (Michael K. Johnson) writes:
>: What about people who want to run BBS's on theis linux boxes? They
>: may well want more than that number of serial ports. There are smart
>: many serial port cards...
>
>True, but a smart serial card would require a new, major device number
>and driver so we might want to use different naming scheme for them.
It might be beneficial to use the same naming scheme for smart serial
cards, too. It would hide the differences of the hardware and programs
could just open /dev/tty<letter><number>, even if some of them were
smart cards and others not.
--
no sig today