10042 lines
396 KiB
Plaintext
10042 lines
396 KiB
Plaintext
From linux Wed Feb 5 09:14:43 1992
|
|
Subject: Mail archive and Mirror information
|
|
To: linux-standards@concert.net
|
|
Date: Wed, 5 Feb 92 8:58:46 EST
|
|
Cc: linux-activists@joker.cs.hut.fi
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@concert.net>
|
|
Sender: abc@concert.net
|
|
|
|
I have started archiving the linux-standards mailing list to the anonymous
|
|
ftp archive on banjo.concert.net (/pub/Linux/linux-standards/mail-archives).
|
|
|
|
Also, I am now mirroring:
|
|
tsx-11.mit.edu:/pub/linux
|
|
tupac-amaru.informatik.rwth-aachen.de:/pub/msdos/replace
|
|
athos.rutgers.edu:/pub/linux
|
|
nic.funet.fi:/pub/OS/Linux (when I can get in)
|
|
|
|
into /pub/Linux/mirrors/*
|
|
|
|
If there are any other sites that I should mirror, let me know.
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
From linux Wed Feb 5 09:14:43 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <22115-0@banjo.concert.net>; Wed, 5 Feb 1992 09:14:07 -0500
|
|
Received: from sumax.seattleu.edu
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA03625;
|
|
Wed, 5 Feb 92 09:14:03 -0500
|
|
Received: by sumax.seattleu.edu id AA31383 (5.65a/IDA-1.4.2
|
|
for linux-standards@concert.net); Wed, 5 Feb 92 06:16:20 -0800
|
|
Date: Wed, 5 Feb 92 06:16:20 -0800
|
|
From: Chuck Boyer <boyer@sumax.seattleu.edu>
|
|
Message-Id: <9202051416.AA31383@sumax.seattleu.edu>
|
|
To: julian@jrc.flinders.edu.au, linux-standards@concert.net
|
|
Subject: Re: FS layout in Linux
|
|
|
|
Thanks Julian, Miss Masey McMillon here. I like your ideas set out here
|
|
in your mail on directories. I vote for your suggestions. My concern is
|
|
that from the beginning I have taken from the various mails a certain
|
|
setup suggestion of partitions for Linux to be up and running; 4M for
|
|
the Root file system, whatever for the main Linux (I have 29M) and
|
|
an additional 8M for swap disk. So, having done that, I find that I
|
|
must put a lot of stuff in /usr (as I begin using the compiler for
|
|
third party stuff it looks for stuff in the headers and Makefiles...)
|
|
so will my 4M Root which has /usr on it (with /usr/bin and /usr/root
|
|
which has the dot.login files) be full too fast? So that sends me
|
|
seeking a way to mount 29M /tmp onto /usr instead, so I don't fear
|
|
running out of space.
|
|
Some information only.
|
|
thanks.
|
|
|
|
From linux Wed Feb 5 12:21:31 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <23122-0@banjo.concert.net>; Wed, 5 Feb 1992 12:19:35 -0500
|
|
Received: from p.lanl.gov by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA07680; Wed, 5 Feb 92 12:19:31 -0500
|
|
Received: from zaphod.lanl.gov by p.lanl.gov (5.65/1.14) id AA24146;
|
|
Wed, 5 Feb 92 09:39:27 -0700
|
|
Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA05275;
|
|
Wed, 5 Feb 92 09:39:28 MST
|
|
Date: Wed, 5 Feb 92 09:39:28 MST
|
|
From: egdorf@zaphod.lanl.gov (Skip Egdorf)
|
|
Message-Id: <9202051639.AA05275@zaphod.lanl.gov.lanl.gov>
|
|
To: abc@concert.net
|
|
Cc: tthorn@daimi.aau.dk, julian@jrc.flinders.edu.au,
|
|
linux-standards@concert.net
|
|
In-Reply-To: Alan B Clegg's message of Wed, 5 Feb 92 8:30:08 EST <9202051337.AB20380@p.lanl.gov>
|
|
Subject: RE: FS layout in Linux
|
|
|
|
|
|
> /site is a nice idea
|
|
> /local nice too.
|
|
|
|
Not sure about this one. Could someone please explain to me the difference
|
|
between /site and /local? I seem to have missed it. No need to send to the
|
|
group, private e-mail is fine [and stupid looks are STILL free].
|
|
|
|
As I am the originator of these, I will reply to the whole net.
|
|
We probably don't need both /site and /local on linux (??).
|
|
They are both hierarchys with bin, lib, etc.
|
|
On my network, /site is mounted from a server for the appropriate
|
|
architecture (eg sun3, sun4, PDP-11 :-) just as /usr is.
|
|
/local is used when a machine a) has a local disk b) has some special
|
|
hardware that needs a special version of a command.
|
|
The typical example is some program that uses graphics, and one machine
|
|
has a special graphics accelerator. The guiding principle is to allow
|
|
any user on the net to sit down at any machine and have a familier
|
|
environment. On one of the normal machines, the command "do-graphics"
|
|
gets the plain vanilla version from /site/bin. On the machine with
|
|
the accelerator, the command comes from /local/bin (before /site/bin in
|
|
PATH). In other words, /local allows the ability to override the SITE-wide
|
|
default command on a LOCAL machine.
|
|
|
|
> Having seperate directories for each package i julian's sense
|
|
> (eg. ci co rcs .. in /app/rcs/bin) is a *very* bad idea.
|
|
|
|
Yup.
|
|
|
|
A *VERY* *VERY* bad idea.
|
|
|
|
> What
|
|
> we need instead is way to shrink packages so that installation
|
|
> AND UNINSTALLATION is trivial. (eg. Interative Unix's approch
|
|
> or Next .pkg).
|
|
|
|
Now, I'm not so sure about this.. How many packages are we looking at to start?
|
|
|
|
When we start getting things like: UNIFY, Lotus 1-2-3, etc, then I agree.
|
|
But for now, [perhaps] tunnel vision is better...
|
|
|
|
There is no reason to be short sighted unless the solution is hard. In
|
|
this case, the solution is easy. And there will be a LOT of packages.
|
|
|
|
In my not-so-humble opinion, the single largest reason for lack of
|
|
acceptance of Unix in the commercial world is the difficulty of
|
|
selling a piece of shrink-wrapped software that just loads. This is
|
|
NOT because of SPARC vs 386 vs whatever. It is because nobody ever
|
|
made a simple standard that ALL third party commands go in /site/bin,
|
|
and ALL support files go in /site/lib (/site/lib/package/... is
|
|
perfectly acceptable as long as the libraries are rooted somewhere.)
|
|
|
|
Take a look at framemaker sometime as an example. For any user to
|
|
use framemaker, the user must run a script that edits a PATH variable
|
|
into the user's .login!!! This, naturally fails for any user who
|
|
does anything even vaguely complex with PATH. Framemaker would not need
|
|
to do this if it could depend on something like /site/bin being in
|
|
every user's PATH and /site/lib being available for creation of
|
|
a /site/lib/frame/...
|
|
|
|
I am not wedded to the name /site. I propose it because I am currently
|
|
using it, and because I believe that ANY scheme that can be agreed
|
|
upon will be better than the anarchy that now exists.
|
|
|
|
Skip Egdorf
|
|
hwe@lanl.gov
|
|
|
|
From linux Wed Feb 5 13:01:37 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Subject: RE: FS layout in Linux
|
|
To: egdorf@zaphod.lanl.gov (Skip Egdorf)
|
|
Date: Wed, 5 Feb 92 13:00:46 EST
|
|
Cc: abc@concert.net, tthorn@daimi.aau.dk, julian@jrc.flinders.edu.au
|
|
From: Alan B Clegg <abc@concert.net>
|
|
Sender: abc@concert.net
|
|
|
|
linux-standards@concert.net
|
|
In-Reply-To: <9202051639.AA05275@zaphod.lanl.gov.lanl.gov>; from "Skip Egdorf" at Feb 5, 92 9:39 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
> > /site is a nice idea
|
|
> > /local nice too.
|
|
|
|
> As I am the originator of these, I will reply to the whole net.
|
|
> We probably don't need both /site and /local on linux (??).
|
|
> They are both hierarchys with bin, lib, etc.
|
|
|
|
Well, why not just call it /usr/local (pretty standard) and allow for the
|
|
future use of /usr/site. Seems that we might be a fair distance from NFS..
|
|
[See end of message for full reasoning behind slight pessimism].
|
|
|
|
> In my not-so-humble opinion, the single largest reason for lack of
|
|
> acceptance of Unix in the commercial world is the difficulty of
|
|
> selling a piece of shrink-wrapped software that just loads. This is
|
|
> NOT because of SPARC vs 386 vs whatever. It is because nobody ever
|
|
> made a simple standard that ALL third party commands go in /site/bin,
|
|
> and ALL support files go in /site/lib (/site/lib/package/... is
|
|
> perfectly acceptable as long as the libraries are rooted somewhere.)
|
|
|
|
Ok, Data General got around this with /var/pkg, with each package living in
|
|
/var/pkg, with links into /usr/bin [I believe, memory is fuzzy].
|
|
|
|
> Take a look at framemaker sometime as an example.
|
|
|
|
I helped with the port of Framemaker 1.2 to the AViiON platform. It IS a mess,
|
|
but it resolves some problems. For those that are unfamiliar with the product,
|
|
it has a shell 'wrapper' that determines the type of platform that you are
|
|
running on, and then executes the correct binaries. This allows all of the
|
|
different versions of Framemaker to be loaded into the same directory tree
|
|
and be available via NFS from the same place for all archetectures.
|
|
|
|
> I am not wedded to the name /site. I propose it because I am currently
|
|
> using it, and because I believe that ANY scheme that can be agreed
|
|
> upon will be better than the anarchy that now exists.
|
|
|
|
I guess I am somewhat biased by my feeling that Linux will [and feel free to
|
|
flame me in private mail if you disagree] be 99% for hackers. I don't see
|
|
commercial vendors running to port their products to it. Please don't get me
|
|
wrong with this, I believe that Linux has great possibilities, but probably
|
|
won't rival SCO/ISC/BSD386/etc for the commercial market. [in fact, I don't
|
|
think that BSD386 will rival the others in the commercial market, but again,
|
|
that is my opinion].
|
|
|
|
UNIX Gurus[tm] have been trying to get this file system separation resolved
|
|
for *YEARS* and [obviously] have not yet gotten it [just] right.
|
|
|
|
I am putting together a proposal for file system structure that I will post
|
|
tomorrow. At that point, have your red pens ready to mark up my thoughts.
|
|
I don't think we can solve the problems of the world [or even of just UNIX],
|
|
but I do think we need to get a decision made so that the next steps can
|
|
begin.
|
|
|
|
-abc
|
|
|
|
BTW: If you note, there has been a lot of heat about the malloc(0) not being
|
|
doing exactly what it does on other platforms, so I can imagine what
|
|
would occur if the 'standards' list came out with a directory structure
|
|
that was 'non-standard'... [grumble grumble]
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux Wed Feb 5 21:35:19 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <25355-0@banjo.concert.net>; Wed, 5 Feb 1992 21:34:25 -0500
|
|
Received: from uceng.UC.EDU by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA15338; Wed, 5 Feb 92 21:34:22 -0500
|
|
Received: by uceng.UC.EDU (16.6/1.34) id AA12842; Wed, 5 Feb 92 21:35:36 -0500
|
|
From: strombrg@uceng.UC.edu (Dan Stromberg)
|
|
Message-Id: <9202060235.AA12842@uceng.UC.EDU>
|
|
Subject: Re: FS layout in Linux
|
|
To: linux-standards@concert.net
|
|
Date: Wed, 5 Feb 92 21:35:34 EST
|
|
X-Mailer: ELM [version 2.3 PL4]
|
|
|
|
|
|
Hi.
|
|
|
|
Before I get started with specifics, let me spell out some of my
|
|
more general biases.
|
|
|
|
First, background:
|
|
As we all know, many true's and'ed with a false, yield a false.
|
|
One true or'ed with many falses, is a true.
|
|
|
|
IMO, there is a parallel here, between general socialism, and
|
|
software socialism. General socialism requires the "and of many true's",
|
|
with the ever-present likelihood of a false - that is, many people
|
|
who might like to make socialism work, messed up by a few more concerned
|
|
with themselves (this is an argument *against* general socialism, BTW).
|
|
Software socialism, seems to work in reverse. One good,
|
|
sturdy package, can dominate a market, over many good sturdy commercial
|
|
packages.
|
|
(Meanwhile, there will probably long be a market for people
|
|
who know how to install and improve those free packages. By the time
|
|
there isn't, we may well all be Eloi - cf. H.G. Well's
|
|
_Time_Machine_).
|
|
It is my opinion that the success of BSD Unix, is largely due
|
|
to the relatively free redistribution restrictions under which it
|
|
was placed.
|
|
Linux takes that further. It's quite redistributable,
|
|
if we ignore annoying little things like US export laws (I'm talking
|
|
about export, or even import-and-re-export, of DES routines - but that's
|
|
only of tangential relevance here in the US, and matters still less to
|
|
a site like nic.funet.fi).
|
|
Anyway.
|
|
To sum up the more political bit of my rambling, before I
|
|
completely lose your interest: I think linux may well really take off,
|
|
if one of the many free MACH-based packages doesn't gain critical mass
|
|
first. Even if one does, there may still be a place for a small
|
|
SysVish system.
|
|
One consequence of a system being in the domain of hackers,
|
|
as BSD has been, is that it will tend to mature into something fairly
|
|
useable, if not pretty nice. Given that there's even so much as a
|
|
marginal possibility of linux becoming fairly substantial, we would do
|
|
the industry a service, to plan a bit beyond our expectations. I'll
|
|
spare you the analogies with what MS-DOS has become to the field.
|
|
|
|
|
|
|
|
Following, are my ideas on the file system, with the above
|
|
points in mind.
|
|
|
|
The idea of a small root partition, with just enough to get
|
|
everything else rolling, is to be protected. It makes fsck'ing on
|
|
reboot nicer, to say nothing of the reduced complexity in getting
|
|
a dead system back up.
|
|
|
|
/bin and /usr/bin, I'd like to see distinct, in part to keep
|
|
the minimal-initial-system, and in part because it breaks things to
|
|
do otherwise, like the Kerberos Version IV "make install".
|
|
|
|
I think S. Egdorf was really onto something, with the use of:
|
|
{/,/usr,/site,/local}{/bin,/etc,/lib}.
|
|
If we could ignore our past, something like:
|
|
{/,/multiuser,/multiuser/package}{/executable,/data}{,/site,/local}
|
|
might be nicer still, but I can't pretend to believe something that
|
|
idealistic would gain much acceptance. I think we can change
|
|
the fs tree a bit, given the indirection provided by $PATH, but
|
|
something like this would probably just be too "different", and
|
|
indeed, somewhat gratuitously so.
|
|
|
|
I agree with tytso, that "etc" has taken on connotations of
|
|
"important system files", and should probably be avoided, except on
|
|
root. "lib" should do.
|
|
|
|
What's the rationale behind putting "linux" in pathnames?
|
|
I'm inclined to believe we'd have better luck with a standard fs tree,
|
|
if we avoided that word in paths. I have *nothing* against linux
|
|
itself, or its name. But will there be anything that is truly
|
|
linux-specific, on the system, but the source code?
|
|
|
|
PATH, LIBPATH, MANPATH, and INCLUDEPATH are each quite worth
|
|
having, IMO.
|
|
|
|
I agree that user's don't absolutely have to have system
|
|
files in the same place, on every machine. The standard distribution
|
|
should be pretty consistent, and should provide guidelines for growth,
|
|
but PATH's are precisely the needed extra level of indirection. I
|
|
realize this ignores bad habits like hard coding /usr/local/lib/gcc-cpp
|
|
into an executable. An env var should be used, or, another name used
|
|
("gcpp"), if it really cannot be put first on the path, with the same
|
|
old name.
|
|
In gcc's case, I like the idea of a cc'ish frontend, that changes
|
|
the PATH and LIBPATH as needed, to get gcc used - on systems that aren't
|
|
using gcc as the primary compiler. 'just an example.
|
|
Of course all of my #!/usr/local/bin/bash scripts aren't going
|
|
anywhere in a hurry... But somehow I'd rather see bash going in /usr/bin,
|
|
or even /bin, than put standard stuff in a "local" directory. In fact,
|
|
I rather favor the idea of a stripped down, bournish bash put in /bin,
|
|
and a full fledged, gigundus bash in /usr/bin - one for scripts, and
|
|
one loaded with interactive features. (I'd like to see Byron's rc
|
|
in /bin, too... but sadly, making it the primary shell for system scripts
|
|
would probably be going too far).
|
|
|
|
Is there a workable alternative to #! ? It's valuable, but it's
|
|
a *hack*. Someday, someone should implement a #$ that scans a (optionally
|
|
intrascript specified) path for the proper interpreter. Or perhaps, it
|
|
should be incorporated into the file system, as is being done with ACL's...
|
|
It might make sense to tackle both at the same time, with the addition of
|
|
an abstraction for "whatever's associated with this file" for tar's sake.
|
|
|
|
A couple of people have mentioned proprietary methods of
|
|
installing and uninstalling packages. I'm familiar with SCO's custom,
|
|
myself - but it didn't strike me as much of a solution, to
|
|
sometimes-complicated installations. Packages that are intended to
|
|
*partially* replace the functionality of other packages, would not
|
|
necessarily work well, with installation programs that reach into
|
|
/usr/bin and such.
|
|
I realize people have been saying lots of separate directories
|
|
is a very bad idea, but I've seen no rationales presented. I'm open to
|
|
be being persuaded otherwise, but honestly I currently like the idea of
|
|
separate directories, for each package. Such is the method being used
|
|
on our primary fileserver at the univ of cinti engineering dept, and
|
|
it seems to work well.
|
|
I've *no* problems with it's speed, and the provided orthogonality
|
|
is elegant. The fileserver is admittedly fast, but the PATH searches
|
|
are almost exclusively done on slower machines, via network communication.
|
|
The fact that many shells (including bash) hash paths, and that the VFS
|
|
would allow nonlinear searches of directories, support the idea as well.
|
|
In fact, the C library could be easily changed to do non-linear scanning
|
|
of PATHs, as well, taking care not to cache *too* much information. As
|
|
UNIX grows, this will only become more important.
|
|
I think both a "custom" program, *and* separate directories, is
|
|
called for, in order to hack in and out those pesky inetd.conf entries,
|
|
and such. But the more simplistic the custom program, the better. I'd
|
|
hate to see things written for a custom program starting to outsmart each
|
|
other - EG, imagine the problems associated with (de)installing two
|
|
packages, both intended to replace intersecting but non-identical portions
|
|
of a third... especially if they try to rename pieces of the third,
|
|
so they can fall back on the old versions...
|
|
|
|
Back to the fs tree:
|
|
I think my ideal system, for both my own personal use, and for a
|
|
large site, would look like:
|
|
|
|
/ home for root.
|
|
/dev How could we ever forget this? :-)
|
|
/bin minimal executables for single user operation
|
|
/etc system configuration stuff. The traditional.
|
|
/lib libraries for single user-only use. Maybe someday a small
|
|
terminfo database, so we could put a full screen editor or
|
|
two in /bin? Actually, that might be about *all* that
|
|
needs to go here... and that could get stuffed into /etc.
|
|
/usr mounted in /etc/rc. Little to nothing but mount points here.
|
|
/usr/bin system executables for multiuser mode.
|
|
/usr/lib system datafiles for multiuser mode.
|
|
/usr/home home directories, or mount points for disks with users....
|
|
/usr/app Little to nothing but mount points.
|
|
/usr/app/name where 'name' is the name of a package
|
|
|
|
/usr/bin and /usr/lib, would be there for old installation
|
|
scripts. They should be deprecated, IMO. I'd actually be pretty
|
|
happy to see a distributed system with present, but empty, /usr/bin
|
|
and /usr/lib.
|
|
Termcap could be an app. Terminfo could be an app. gcc
|
|
could be an app, to make room for any other compilers that may be
|
|
coming. Shell-of-the-month's that aren't trusted enough for system
|
|
scripts, could be apps. The idea is that no piece of software is really
|
|
central to the system's existence. Ok, init and /bin/sh probably
|
|
should, though the sh is arguable.
|
|
Ideally, /,/bin,/etc, /lib, and /dev could be copied to a
|
|
(moderately sized) floppy filesystem, to get another system running
|
|
enough to de-tar an entire distribution from diskettes/tapes/cd-roms/
|
|
network, and edit some config files, or invoke some simplistic
|
|
installation scripts/binaries.
|
|
In fact, a really nicely polished system might have two
|
|
password files: one for single user mode, on root, and one for multiuser,
|
|
on /usr somewhere, maybe /usr/etc. I'm less than happy about the
|
|
number of systems I've seen, that had /etc/passwd (and attendant
|
|
databases), outgrow their root partition. Putting just logins
|
|
for root, system accounts, and sysadmins in /etc/passwd (perhaps only
|
|
these would be allowed to log in on the console), and the bulk of
|
|
users in /usr/etc/passwd, would be kind of nice.
|
|
|
|
My comments on the filesystem layout are done.
|
|
|
|
S. Egdorf has mentioned that much of the reason for UNIX's
|
|
lack of acceptance, is its lack of shrink-wrapped software. I support
|
|
his conclusion (that /site in some form, make sense, though it
|
|
could be replaced fully or in part, but /usr/app), but not his
|
|
reasoning... IMO, this is technically, and politically (I'll not get
|
|
started again...) a reason for UNIX's resilience, as well.
|
|
The fact that we don't have something as constrictive as
|
|
the BIOS hampering UNIX's growth, is in part a strength. POSIX
|
|
is testament to the flexibility, and viability, of a Better Way.
|
|
Honestly, I shudder at all the emphasis that's been put
|
|
on ABI's lately. It's great for distribution, but it's harmful to
|
|
flexibility. ...and what we're seeing is the same problems hashed
|
|
out, more cryptically. In the C world, we worry that we don't
|
|
have functions present with names like "strrchr". In the ABI world,
|
|
we have to concern ourselves with missing system calls, often identified
|
|
by *numbers*. Semantically, I believe they almost identical, but one
|
|
is considerably less mnemonic, and much more given to being used for
|
|
multiple, conflicting purpose.
|
|
IMO, it makes far more sense to compile ML or Eiffel or whatever,
|
|
into ANSI C, extended just enough to allow symbolic debugging of the
|
|
source language.
|
|
Writing or compiling to portable C, isn't all *that* hard...
|
|
It's just an unfortunate part of the C tradition, not to.
|
|
|
|
Anyway. Those're my thoughts.
|
|
|
|
(Skip, you get my vote for best contribution to the layout discussion,
|
|
*and* most emperor's-new-clothes idea. That's something of an Honour,
|
|
IMO - no sarcasm whatsoever)
|
|
|
|
|
|
From linux Thu Feb 6 09:18:34 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Subject: DRAFT of File System document
|
|
To: linux-standards@concert.net
|
|
Date: Thu, 6 Feb 92 9:17:37 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@concert.net>
|
|
Sender: abc@concert.net
|
|
|
|
Please let me know what you think of this [pro and con arguments are requested]
|
|
|
|
=====SNIP HERE=====
|
|
The following is being submitted by Alan Clegg [abc@concert.net] as the
|
|
proposed standard for directory file structure under Linux.
|
|
|
|
Complete implementation of this file structure is completely voluntary,
|
|
and will not be enforced, but will be recommended. This specification
|
|
is released as guidelines for people porting and writing software for
|
|
the Linux Operating System to allow easy software installation, upgrade,
|
|
and tailoring on already installed systems.
|
|
|
|
Root Directory:
|
|
|
|
Files:
|
|
{none defined by spec}
|
|
|
|
Directories:
|
|
bin dev etc lib mnt usr
|
|
|
|
Rationale:
|
|
The root directory should not be cluttered with files or
|
|
directories, and should contain no user programs.
|
|
|
|
/bin Directory:
|
|
|
|
Files:
|
|
sh init mount umount dd cat ls fsck [?others?]
|
|
[should ls be there if 'echo *' works?]
|
|
|
|
Directories:
|
|
{none defined by spec}
|
|
|
|
Rationale:
|
|
The /bin directory should contain programs that are vital
|
|
to the restoration of other file systems in the case of
|
|
a corrupting crash. No executable in /bin should require
|
|
any other file system to be mounted to execute correctly.
|
|
|
|
/dev Directory:
|
|
|
|
Files:
|
|
{device files}
|
|
|
|
Directories:
|
|
{none define by spec}
|
|
|
|
Rationale:
|
|
Standard UNIX[tm] device files. This directory should contain
|
|
device entries for all devices that are supported in the
|
|
standard kernel, even if the hardware device does not exist
|
|
on the system. [comments?]
|
|
|
|
/etc Directory:
|
|
|
|
Files:
|
|
mtab passwd rc ttytab {and as needed}
|
|
|
|
Directories:
|
|
{none defined by spec}
|
|
|
|
Rationale:
|
|
Standard location of files required during system boot. Files
|
|
in this directory are usually system specific. Most will
|
|
require human intervention during system upgrade.
|
|
|
|
/lib Directory:
|
|
|
|
Files:
|
|
{libraries required for system initialization}
|
|
|
|
Directories:
|
|
{none defined by spec}
|
|
|
|
Rationale:
|
|
To keep the size of the root partition small (if separate from
|
|
/usr), the files in this directory should only be ones required
|
|
by files in the root partition.
|
|
|
|
/mnt Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
Directories:
|
|
NONE
|
|
|
|
Rationale:
|
|
Standard mount point for external (transient) file systems.
|
|
Must be available for sub-system installation. Should remain
|
|
as an empty directory.
|
|
|
|
/tmp Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
Directories:
|
|
NONE
|
|
|
|
Rationale:
|
|
Temporary file space available for general program use. May
|
|
become a mounted partition upon system boot. [Minimum size?]
|
|
|
|
/usr Directory:
|
|
|
|
Files:
|
|
{none defined by spec}
|
|
|
|
Directories:
|
|
adm bin spool local lib etc man include src tmp linux users
|
|
|
|
Rationale:
|
|
/usr is the mount point for the second major (after root)
|
|
hierarchy of file structure and is discussed in the next
|
|
section.
|
|
|
|
/usr/adm Directory:
|
|
|
|
Files:
|
|
{none defined in spec}
|
|
|
|
Directories:
|
|
{none defined in spec}
|
|
|
|
Rationale:
|
|
Location of log files and accounting information.
|
|
|
|
/usr/bin Directory:
|
|
|
|
Files:
|
|
{all files from standard distribution not contined in /bin}
|
|
|
|
Directories:
|
|
{none defined in spec}
|
|
|
|
Rationale:
|
|
contains 'drop-in' executables that are considered to be
|
|
standard to the UNIX system. These files should NOT be
|
|
Linux specific, but should have the same function as their
|
|
UNIX equivalents.
|
|
|
|
/usr/etc Directory:
|
|
|
|
Files:
|
|
{none defined in spec}
|
|
|
|
Directories:
|
|
{none defined in spec}
|
|
|
|
Rationale:
|
|
contains configuration files for any files in /usr/bin. helps
|
|
to keep /etc clean and small.
|
|
|
|
/usr/spool Directory:
|
|
|
|
Files:
|
|
{none defined in spec}
|
|
|
|
Directories:
|
|
uucp mail
|
|
|
|
Rationale:
|
|
containes spool files for mail, printing, uucp transfer, etc.
|
|
May be a mount point for another volume.
|
|
|
|
/usr/local Directory:
|
|
|
|
Files:
|
|
{none defined in spec}
|
|
|
|
Directories:
|
|
bin lib etc man src
|
|
|
|
Rationale:
|
|
contains files local to the specific system. will not be
|
|
modified by upgrade process.
|
|
|
|
/usr/lib Directory:
|
|
|
|
Files:
|
|
libc.a crt0.s {and as needed}
|
|
|
|
Directories:
|
|
{none defined in spec}
|
|
|
|
Rationale:
|
|
location for library files required for multi-user system
|
|
operation. This is the directory where program libraries
|
|
should reside.
|
|
|
|
/usr/man Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
Directories:
|
|
man1 man2 man3 man4 man5 man6 man7 man8
|
|
|
|
Rationale:
|
|
Contains manual pages for programs that are standard with
|
|
Linux.
|
|
|
|
/usr/include Directory:
|
|
|
|
Files:
|
|
{programmers include files}
|
|
|
|
Directories:
|
|
{as needed}
|
|
|
|
Rationale:
|
|
Standard place for system include files.
|
|
|
|
/usr/src Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
Directories:
|
|
bin lib linux usr.bin usr.linux
|
|
|
|
Rationale:
|
|
Contains source code for all applications in the release.
|
|
/usr/src/linux contains directories required for kernel builds.
|
|
|
|
/usr/tmp Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
|
|
Directories:
|
|
NONE
|
|
|
|
Rationale:
|
|
Used as additional scratch space for programs. If /tmp is
|
|
a mounted file system, /usr/tmp may be a symbolic link to
|
|
/tmp.
|
|
|
|
/usr/linux Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
Directories:
|
|
bin lib etc
|
|
|
|
Rationale:
|
|
Contains programs that are "linux specific" and programs that
|
|
semantics are different from the standard UNIX usage.
|
|
|
|
/usr/users Directory: [Probably /home]
|
|
|
|
Files:
|
|
NONE
|
|
|
|
Directories:
|
|
{one for each user, except root}
|
|
|
|
Rationale:
|
|
Users home directories. [Root's home directory should be
|
|
on the root partition somewhere.]
|
|
|
|
=====SNIP HERE=====
|
|
|
|
Please feel free to comment on these ideas, and let me know what you think.
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux Thu Feb 6 10:16:12 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <27511-0@banjo.concert.net>; Thu, 6 Feb 1992 10:15:19 -0500
|
|
Received: from wrzx01.rz.uni-wuerzburg.de
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA19251;
|
|
Thu, 6 Feb 92 10:14:45 -0500
|
|
Received: from winx13.informatik.uni-wuerzburg.de
|
|
by wrzx01.rz.uni-wuerzburg.de (4.1/uniwue-M-2.02) id AA01950;
|
|
Thu, 6 Feb 92 16:13:54 +0100
|
|
Received: by winx13.informatik.uni-wuerzburg.de (4.1/uniwue-C-2.0) id AA26668;
|
|
Thu, 6 Feb 92 16:13:36 +0100
|
|
From: Dirk Hohndel <hohndel@informatik.uni-wuerzburg.de>
|
|
Message-Id: <9202061513.AA26668@winx13.informatik.uni-wuerzburg.de>
|
|
Subject: Re: DRAFT of File System document
|
|
To: linux-standards@concert.net
|
|
Date: Thu, 6 Feb 92 16:13:36 MET
|
|
In-Reply-To: <9202061431.AA13629@winx03.informatik.uni-wuerzburg.de>; from "Alan B Clegg" at Feb 6, 92 9:17 am
|
|
X-Mailer: ELM [version 2.3 PL0]
|
|
|
|
Alan B Clegg writes
|
|
>
|
|
> Root Directory:
|
|
>
|
|
|
|
ok
|
|
|
|
>
|
|
> /bin Directory:
|
|
>
|
|
> Files:
|
|
> sh init mount umount dd cat ls fsck [?others?]
|
|
|
|
programs to set up / check networking (a la ifconfig)
|
|
|
|
> [should ls be there if 'echo *' works?]
|
|
|
|
maybe yes, some options of ls might be useful in single user mode
|
|
|
|
> Rationale:
|
|
> The /bin directory should contain programs that are vital
|
|
> to the restoration of other file systems in the case of
|
|
> a corrupting crash. No executable in /bin should require
|
|
> any other file system to be mounted to execute correctly.
|
|
|
|
Good point
|
|
|
|
>
|
|
> /dev Directory:
|
|
>
|
|
> Rationale:
|
|
> Standard UNIX[tm] device files. This directory should contain
|
|
> device entries for all devices that are supported in the
|
|
^^^
|
|
> standard kernel, even if the hardware device does not exist
|
|
> on the system. [comments?]
|
|
|
|
Why ? a minimal configuration doesn't need devices for tape, scanner, 16 COMs
|
|
8 LPTs 15 disks and so on
|
|
|
|
>
|
|
> /etc Directory:
|
|
>
|
|
> Files:
|
|
> mtab passwd rc ttytab {and as needed}
|
|
|
|
group hosts (!) printcap
|
|
|
|
>
|
|
> /lib Directory:
|
|
|
|
ok
|
|
|
|
>
|
|
> /mnt Directory:
|
|
|
|
ok
|
|
|
|
>
|
|
> /tmp Directory:
|
|
|
|
ok
|
|
|
|
> /usr/adm Directory:
|
|
>
|
|
> Files:
|
|
> {none defined in spec}
|
|
|
|
adduser, rmuser and related stuff ?
|
|
>
|
|
> Directories:
|
|
> {none defined in spec}
|
|
>
|
|
> Rationale:
|
|
> Location of log files and accounting information.
|
|
Maybe programms of administrative charakter not needed in single user mode ?
|
|
|
|
>
|
|
> /usr/bin Directory:
|
|
>
|
|
> Rationale:
|
|
> contains 'drop-in' executables that are considered to be
|
|
> standard to the UNIX system. These files should NOT be
|
|
> Linux specific, but should have the same function as their
|
|
> UNIX equivalents.
|
|
maybe gcc should be HERE !
|
|
|
|
>
|
|
> /usr/etc Directory:
|
|
>
|
|
|
|
ok
|
|
|
|
> /usr/spool Directory:
|
|
|
|
ok
|
|
|
|
>
|
|
> /usr/local Directory:
|
|
>
|
|
> Files:
|
|
> {none defined in spec}
|
|
>
|
|
> Directories:
|
|
> bin lib etc man src
|
|
>
|
|
> Rationale:
|
|
> contains files local to the specific system. will not be
|
|
> modified by upgrade process.
|
|
|
|
does that meen that in our standard release this directory is empty ?
|
|
|
|
>
|
|
> /usr/lib Directory:
|
|
>
|
|
> Rationale:
|
|
> location for library files required for multi-user system
|
|
> operation. This is the directory where program libraries
|
|
> should reside.
|
|
|
|
what about shared libs ?
|
|
|
|
>
|
|
> /usr/man Directory:
|
|
>
|
|
|
|
ok
|
|
|
|
>
|
|
> /usr/include Directory:
|
|
>
|
|
|
|
ok
|
|
|
|
>
|
|
> /usr/src Directory:
|
|
>
|
|
> Rationale:
|
|
> Contains source code for all applications in the release.
|
|
> /usr/src/linux contains directories required for kernel builds.
|
|
|
|
good idea
|
|
|
|
>
|
|
> /usr/tmp Directory:
|
|
|
|
ok
|
|
|
|
>
|
|
> /usr/linux Directory:
|
|
|
|
ok
|
|
|
|
> /usr/users Directory: [Probably /home]
|
|
|
|
this should not be ruled, because we should force (urge, beg,...) people to
|
|
leave their habbit. I think someone is used to /home/joe the otherone to
|
|
/u/joe or anything else
|
|
|
|
|
|
All in all : accepted !!
|
|
|
|
Dirk
|
|
|
|
--
|
|
Dirk Hohndel Lehrstuhl fuer Informatik I
|
|
hohndel@informatik.uni-wuerzburg.de Universitaet Wuerzburg
|
|
Tel. 0931 / 888-5057 Am Hubland
|
|
Fax. 0931 / 888-4600 D-8700 Wuerzburg
|
|
|
|
From linux Thu Feb 6 10:21:58 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <27584-0@banjo.concert.net>; Thu, 6 Feb 1992 10:21:21 -0500
|
|
Received: from daimi.aau.dk by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA19475; Thu, 6 Feb 92 10:21:17 -0500
|
|
Received: from bentley.daimi.aau.dk by daimi.aau.dk
|
|
with SMTP (5.61++/IDA-1.2.8) id AA03550; Thu, 6 Feb 92 16:19:42 +0100
|
|
Received: by bentley.daimi.aau.dk (5.64/1.34) id AA17286;
|
|
Thu, 6 Feb 92 16:19:36 +0100
|
|
From: poe@daimi.aau.dk
|
|
Message-Id: <9202061519.AA17286@bentley.daimi.aau.dk>
|
|
Subject: Re: FS layout in Linux
|
|
To: strombrg@uceng.UC.edu (Dan Stromberg)
|
|
Date: Thu, 6 Feb 92 16:19:33 MET
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: <9202060235.AA12842@uceng.UC.EDU>; from "Dan Stromberg" at Feb 5, 92 9:35 pm
|
|
Organization: DAIMI, Computer Science Department of Aarhus University
|
|
Phone: 86 20 27 11 - 5034
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
> Hi.
|
|
>
|
|
> Before I get started with specifics, let me spell out some of my
|
|
> more general biases.
|
|
>
|
|
|
|
[political stuff deleted]
|
|
|
|
>
|
|
> Following, are my ideas on the file system, with the above
|
|
> points in mind.
|
|
>
|
|
> The idea of a small root partition, with just enough to get
|
|
> everything else rolling, is to be protected. It makes fsck'ing on
|
|
> reboot nicer, to say nothing of the reduced complexity in getting
|
|
> a dead system back up.
|
|
>
|
|
> /bin and /usr/bin, I'd like to see distinct, in part to keep
|
|
> the minimal-initial-system, and in part because it breaks things to
|
|
> do otherwise, like the Kerberos Version IV "make install".
|
|
>
|
|
> I think S. Egdorf was really onto something, with the use of:
|
|
> {/,/usr,/site,/local}{/bin,/etc,/lib}.
|
|
|
|
Agreed.
|
|
|
|
> If we could ignore our past, something like:
|
|
> {/,/multiuser,/multiuser/package}{/executable,/data}{,/site,/local}
|
|
> might be nicer still, but I can't pretend to believe something that
|
|
> idealistic would gain much acceptance.
|
|
|
|
Ideal, hmmmph.
|
|
|
|
> PATH, LIBPATH, MANPATH, and INCLUDEPATH are each quite worth
|
|
> having, IMO.
|
|
|
|
Certainly.
|
|
|
|
>
|
|
> Is there a workable alternative to #! ? It's valuable, but it's
|
|
> a *hack*. Someday, someone should implement a #$ that scans a (optionally
|
|
> intrascript specified) path for the proper interpreter. Or perhaps, it
|
|
> should be incorporated into the file system, as is being done with ACL's...
|
|
> It might make sense to tackle both at the same time, with the addition of
|
|
> an abstraction for "whatever's associated with this file" for tar's sake.
|
|
|
|
Ugh! #! must only accept an absolute path for the interpreter, or you open
|
|
a can of worms, securitywise.
|
|
|
|
> Back to the fs tree:
|
|
> I think my ideal system, for both my own personal use, and for a
|
|
> large site, would look like:
|
|
>
|
|
> / home for root.
|
|
> /dev How could we ever forget this? :-)
|
|
> /bin minimal executables for single user operation
|
|
> /etc system configuration stuff. The traditional.
|
|
> /lib libraries for single user-only use. Maybe someday a small
|
|
> terminfo database, so we could put a full screen editor or
|
|
> two in /bin? Actually, that might be about *all* that
|
|
> needs to go here... and that could get stuffed into /etc.
|
|
> /usr mounted in /etc/rc. Little to nothing but mount points here.
|
|
> /usr/bin system executables for multiuser mode.
|
|
> /usr/lib system datafiles for multiuser mode.
|
|
> /usr/home home directories, or mount points for disks with users....
|
|
> /usr/app Little to nothing but mount points.
|
|
> /usr/app/name where 'name' is the name of a package
|
|
>
|
|
> /usr/bin and /usr/lib, would be there for old installation
|
|
> scripts. They should be deprecated, IMO. I'd actually be pretty
|
|
> happy to see a distributed system with present, but empty, /usr/bin
|
|
> and /usr/lib.
|
|
|
|
I don't really see anything wrong with /usr/lib and /usr/bin.
|
|
|
|
> Termcap could be an app. Terminfo could be an app. gcc
|
|
> could be an app, to make room for any other compilers that may be
|
|
> coming. Shell-of-the-month's that aren't trusted enough for system
|
|
> scripts, could be apps. The idea is that no piece of software is really
|
|
> central to the system's existence. Ok, init and /bin/sh probably
|
|
> should, though the sh is arguable.
|
|
|
|
Does this mean that termcap and terminfo should be programs (applications? :-)
|
|
or shuld they just reside in /usr/app
|
|
|
|
> Ideally, /,/bin,/etc, /lib, and /dev could be copied to a
|
|
> (moderately sized) floppy filesystem, to get another system running
|
|
> enough to de-tar an entire distribution from diskettes/tapes/cd-roms/
|
|
> network, and edit some config files, or invoke some simplistic
|
|
> installation scripts/binaries.
|
|
|
|
Good idea.
|
|
|
|
> In fact, a really nicely polished system might have two
|
|
> password files: one for single user mode, on root, and one for multiuser,
|
|
> on /usr somewhere, maybe /usr/etc. I'm less than happy about the
|
|
> number of systems I've seen, that had /etc/passwd (and attendant
|
|
> databases), outgrow their root partition. Putting just logins
|
|
> for root, system accounts, and sysadmins in /etc/passwd (perhaps only
|
|
> these would be allowed to log in on the console), and the bulk of
|
|
> users in /usr/etc/passwd, would be kind of nice.
|
|
|
|
Never heard of YP^H^H NIS?
|
|
|
|
> My comments on the filesystem layout are done.
|
|
>
|
|
> S. Egdorf has mentioned that much of the reason for UNIX's
|
|
> lack of acceptance, is its lack of shrink-wrapped software. I support
|
|
> his conclusion (that /site in some form, make sense, though it
|
|
> could be replaced fully or in part, but /usr/app), but not his
|
|
> reasoning... IMO, this is technically, and politically (I'll not get
|
|
> started again...) a reason for UNIX's resilience, as well.
|
|
> The fact that we don't have something as constrictive as
|
|
> the BIOS hampering UNIX's growth, is in part a strength. POSIX
|
|
> is testament to the flexibility, and viability, of a Better Way.
|
|
|
|
Does anyone really think we will ever have shrik-wrapped apps. for linux??
|
|
|
|
I view linux as a hackers system, where we can have source for everything, and
|
|
not have to rely on shrinkwrapped binaries-only packages.
|
|
|
|
On another note, beware of the tendency to make linux an "design by commitee"
|
|
system. I belive that linux is as good as it is, because it was designed and
|
|
implemented by one man (Linus). This doesn't mean that we should stop making
|
|
contributions and extensions, as Linus can't do everything for us.
|
|
|
|
Trying to forge standards at this early stage seems a bit futile to me,
|
|
time will tell where linux goes.... (This will probably make my mailbox
|
|
bloat with flames, Oh well..)
|
|
|
|
- Peter.
|
|
|
|
From linux Thu Feb 6 10:34:30 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Subject: Re: DRAFT of File System document
|
|
To: linux-standards@concert.net
|
|
Date: Thu, 6 Feb 92 10:33:52 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@concert.net>
|
|
Sender: abc@concert.net
|
|
|
|
> > /bin Directory:
|
|
> > sh init mount umount dd cat ls fsck [?others?]
|
|
> programs to set up / check networking (a la ifconfig)
|
|
Yes, I could not think of all the possibilities, just be sure that they fit
|
|
in with the Rationale... 8-)
|
|
|
|
> > [should ls be there if 'echo *' works?]
|
|
> maybe yes, some options of ls might be useful in single user mode
|
|
Agreed.
|
|
|
|
> > /dev Directory:
|
|
> >
|
|
> > Rationale:
|
|
> > Standard UNIX[tm] device files. This directory should contain
|
|
> > device entries for all devices that are supported in the
|
|
> ^^^
|
|
> > standard kernel, even if the hardware device does not exist
|
|
> > on the system. [comments?]
|
|
>
|
|
> Why ? a minimal configuration doesn't need devices for tape, scanner, 16 COMs
|
|
> 8 LPTs 15 disks and so on
|
|
|
|
Right. Probably don't need all of 'em..
|
|
|
|
> > /usr/adm Directory:
|
|
> > Files:
|
|
> adduser, rmuser and related stuff ?
|
|
Yup.. but gotta wait till someone ports them.. 8-)
|
|
|
|
> > Rationale:
|
|
> > Location of log files and accounting information.
|
|
> Maybe programms of administrative charakter not needed in single user mode ?
|
|
|
|
Well, yes-and-no. Perhaps these files should really reside in /usr/bin?
|
|
This is where the call gets hard to make.
|
|
|
|
> > /usr/bin Directory:
|
|
> maybe gcc should be HERE !
|
|
Yes!
|
|
|
|
> > /usr/local Directory:
|
|
> > Rationale:
|
|
> > contains files local to the specific system. will not be
|
|
> > modified by upgrade process.
|
|
> does that meen that in our standard release this directory is empty ?
|
|
|
|
Yes.
|
|
|
|
> > /usr/lib Directory:
|
|
> what about shared libs ?
|
|
Dunno.. where *DO* they live? I would assume that /usr/lib is the right place.
|
|
|
|
> > /usr/users Directory: [Probably /home]
|
|
> this should not be ruled, because we should force (urge, beg,...) people to
|
|
> leave their habbit. I think someone is used to /home/joe the otherone to
|
|
> /u/joe or anything else
|
|
|
|
None of these are rules, since I know that everyone is *VERY* opinionated.
|
|
I have taken the best arguments for each of the file systems and come up with
|
|
this. It seems that it is very close to the BSD 4.3 structure (although I
|
|
don't have access to one of them to check it out).
|
|
|
|
> All in all : accepted !!
|
|
|
|
Thanks,
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux Thu Feb 6 14:24:20 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Subject: Re: DRAFT of File System Document
|
|
To: linux-standards@concert.net
|
|
Date: Thu, 6 Feb 92 14:24:03 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@concert.net>
|
|
Sender: abc@concert.net
|
|
|
|
EEEEEeeeeekkkk!
|
|
|
|
The list of files in each directory was a *SAMPLE*. I was not meaning to list
|
|
every single file... that will come later.
|
|
|
|
I must say, so-far, the comments have been very positive. Thanks!
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux Thu Feb 6 14:25:20 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <28924-0@banjo.concert.net>; Thu, 6 Feb 1992 14:22:35 -0500
|
|
Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA23545; Thu, 6 Feb 92 14:22:33 -0500
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA22168;
|
|
Thu, 6 Feb 92 14:22:12 -0500
|
|
Date: Thu, 6 Feb 92 14:22:12 -0500
|
|
From: eichin@ATHENA.MIT.edu ("Mark W. Eichin")
|
|
Message-Id: <9202061922.AA22168@tsx-11.MIT.EDU>
|
|
To: abc@concert.net
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: Alan B Clegg's message of Thu, 6 Feb 92 9:17:37 EST <9202061449.AA16809@MIT.EDU>
|
|
Subject: re: DRAFT of File System document
|
|
|
|
Overall it looks good; I've got a few comments on specific sections...
|
|
|
|
/bin Directory:
|
|
> Rationale:
|
|
> The /bin directory should contain programs that are vital
|
|
> to the restoration of other file systems in the case of
|
|
Add mknod to the list? if you lose some device (or change the
|
|
kernel in such a way that device numbers change) you're really going
|
|
to need it...
|
|
|
|
/dev Directory:
|
|
Many Unix systems also put MAKEDEV in here - a shell script
|
|
which takes "common names" as arguments and creates the devices to
|
|
match (ie. MAKEDEV pty 8 will make the first 8 pty master/slave
|
|
pairs.)
|
|
|
|
/etc Directory:
|
|
> Rationale:
|
|
> Standard location of files required during system boot. Files
|
|
I believe the convention here has evolved to *configuration*
|
|
files need at boot time; the rc files are a special case, since they
|
|
are config files but they happen to be executable... Otherwise, there
|
|
are really no programs that belong in etc.
|
|
|
|
/usr/tmp:
|
|
> Rationale:
|
|
> Used as additional scratch space for programs. If /tmp is
|
|
> a mounted file system, /usr/tmp may be a symbolic link to
|
|
> /tmp.
|
|
On most Unix systems I'm familiar with, there is an important
|
|
semantic distinction between /tmp and /usr/tmp which precludes the use
|
|
of a symlink: /tmp is cleaned at boot time, /usr/tmp isn't. Thus, many
|
|
programs keep "autosave" files in /usr/tmp (there are very good
|
|
reasons not to keep them in the same directory as the original, for
|
|
example if the original is a *slow* (ie. networked) or nearly full
|
|
file system, you take a real hit when doing autosaves -- but you want
|
|
to do them as often as you can get away with...)
|
|
|
|
/usr/linux Directory:
|
|
> Rationale:
|
|
> Contains programs that are "linux specific" and programs that
|
|
> semantics are different from the standard UNIX usage.
|
|
This sounds bad for the same reason that "/usr/ucb" is -- that
|
|
there isn't anything truly "linux specific". Can you name things that
|
|
really should go here?
|
|
As for "different" programs, that'll just be a reason for me
|
|
*not* to have /usr/linux/bin in my path...
|
|
|
|
/usr/local Directory:
|
|
Well, I suppose this is the right thing to do at this level,
|
|
but let me tell a few stories from my experiences...
|
|
1) At Cygnus Support, internally we have three categories of
|
|
installed packages: "latest", "vintage", and "unsupported". Latest and
|
|
vintage typically have overlapping contents; latest is whatever got
|
|
most recently compiled, whereas vintage is the "long term stable"
|
|
version. "unsupported" means anything we're not paid to support (for
|
|
example, X11 ends up here, as unsupported/X11/{bin,lib...}; most
|
|
things off the net end up here.) We specifically don't *have* a
|
|
/usr/local because so many things come off the net with /usr/local
|
|
hard coded, and we have to find those paths ourselves (our customers
|
|
to install our packages under /usr/cygnus - we can't preempt their
|
|
/usr/local.)
|
|
2) At MIT (Project Athena), *everything* is out on the net (it
|
|
is a pain to update a full software load on 1K workstations, so only
|
|
the base OS is on them.) There are different size packages, from the
|
|
full Athena setup (which gets put under one mountpoint, so that
|
|
symlinks from the workstation local disk get "filled in") to smaller
|
|
"lockers", some of which have groups of programs (such as the "gnu"
|
|
locker), and some of which have single programs (such as the lockers
|
|
for saber, calendar, S...). For consistency, lockers all go under the
|
|
/mit directory (which is, granted, very provincial :-) however, there
|
|
is an "add" alias which automatically adds the locker's bin directory
|
|
to the user's path. This leads to some extensive paths; mine only has
|
|
17 elements in it, but I haven't been using many packages this
|
|
session. The path length is not usually a major performance problem,
|
|
at least for executable searches, partially because of the hashed
|
|
directory cache in the shell; "man" sometimes gets slow, particularly
|
|
when it *doesn't* find the name because you misspelled it and has to
|
|
search 10 directories per path entry for the rest. [Summary: don't be
|
|
afraid of long paths.] /usr/local just isn't general enough to cover
|
|
this, though it gets used occasionally on "private" workstations.
|
|
As for the base operating system, some work was done on
|
|
minimizing the contents of the root (so that fast local disk could be
|
|
more profitably used as swap, tmp, and AFS cache space) so some
|
|
interesting distinctions were made (and *lots* of symlinks...) For
|
|
example, /bin contained things that had to be on the root; /usr/bin
|
|
contained things that didn't. (Recently, /usr/athena/{bin,lib,etc}
|
|
were also added to cover things that Athena was specifically
|
|
responsible for rather than scattering them elsewhere in the
|
|
filesystem.)
|
|
|
|
Another story: if you've kept up with Plan 9 from Bell Labs,
|
|
their shell ("rc" - and I mean the Plan 9 version, *not* the clone
|
|
available on the net) *doesn't* support a PATH. All executables are in
|
|
/bin; you just "mount" other directories "after" /bin, so that the
|
|
filesystem shows /bin as one (very long) directory. This is going
|
|
somewhat in the other direction (and is not very practical to us, as
|
|
Linux doesn't support union directories [nor does any operating system
|
|
other than Plan 9 as far as I know]) but has some merit to it. (These
|
|
"mounts" are entirely per process, not system wide, though your child
|
|
processes inherit them.)
|
|
|
|
_Mark_ <eichin@athena.mit.edu> N1DPU
|
|
MIT Student Information Processing Board
|
|
Cygnus Support <eichin@cygnus.com>
|
|
|
|
From linux Thu Feb 6 14:52:21 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <29065-0@banjo.concert.net>; Thu, 6 Feb 1992 14:51:31 -0500
|
|
Received: from istwok.ods.com (twok.ods.com)
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA23686;
|
|
Thu, 6 Feb 92 14:51:26 -0500
|
|
Received: by istwok.ods.com id AA04010 (5.65c/IDA-1.3.5);
|
|
Thu, 6 Feb 1992 13:52:11 -0600
|
|
From: David Engel <david@istwok.ods.com>
|
|
Message-Id: <199202061952.AA04010@istwok.ods.com>
|
|
Subject: Re: DRAFT of File System document
|
|
To: abc@concert.net (Alan B Clegg)
|
|
Date: Thu, 6 Feb 92 13:52:10 CST
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: <199202061424.AA00343@istwok.ods.com>; from "Alan B Clegg" at Feb 6, 92 9:17 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
> Root Directory:
|
|
>
|
|
> Files:
|
|
> {none defined by spec}
|
|
|
|
For those who boot from the hard disk (using shoelace or whatever), we
|
|
probably want to put the kernel itself here. We probably also want to
|
|
give it a "standard" name so programs like ps can get information from
|
|
it when /dev/kmem is implemented.
|
|
|
|
David
|
|
|
|
From linux Thu Feb 6 16:03:17 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <29648-0@banjo.concert.net>; Thu, 6 Feb 1992 16:02:35 -0500
|
|
Received: from golem.wcc.govt.nz by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA24819; Thu, 6 Feb 92 16:01:53 -0500
|
|
Received: from csc.wcc.govt.nz by golem.wcc.govt.nz id <AA20765-5.65a+VUW/4.0>;
|
|
Fri, 7 Feb 92 10:03:32 +1300
|
|
Received: by csc.wcc.govt.nz (MX V3.0) id 1045; Fri, 07 Feb 1992 10:03:54 EST
|
|
Sender: hamilton <hamilton@csc.wcc.govt.nz>
|
|
Date: Fri, 07 Feb 1992 10:03:28 EST
|
|
From: hamilton@csc.wcc.govt.nz
|
|
To: linux-standards@concert.net
|
|
Cc: hamilton@csc.wcc.govt.nz
|
|
Message-Id: <00955CBC.F0614000.1045@csc.wcc.govt.nz>
|
|
Subject: FS layout in Linux
|
|
|
|
|
|
I thought that Theodore Ts'o (tytso@athena.mit.edu) made a very good
|
|
point about a large number of hierarchies off root being a problem.
|
|
Any decisions "we" make have to consider the typical target platform.
|
|
And I agree also agree with his statement that sym links can be a
|
|
source of confusion. We use the following for local stuff:
|
|
|
|
On our two small AIX and Ultrix boxes we have the following scheme
|
|
|
|
/usr/local/app/
|
|
/usr/local/users/
|
|
/usr/local/bin/
|
|
/usr/local/lib/
|
|
/usr/local/etc/
|
|
/usr/local/README
|
|
|
|
We try to stick ALL local stuff as possible somewhere under /usr/local.
|
|
It then becomes quite easy to put all local (frequently changing stuff)
|
|
in the same partition. It also simplifies backups and upgrades - we
|
|
take extra care to backup /usr/local.
|
|
|
|
I don't have strong opinions on the fs hierarchy - I'm not pushing our
|
|
this particular scheme - I just thought I add another possibility into
|
|
the melting pot.
|
|
|
|
The one thing I would like to push is some strategic (perhaps
|
|
standardised) placement of README files around the hierarchy where I
|
|
can find out the logic and convensions contained within (plus misc
|
|
general notes).
|
|
________________
|
|
Michael Hamilton, Computer Services Section, Wellington City Council, P.O. Box
|
|
2199, Wellington, New Zealand. Phone: (64) (4) 801-3317 FAX: (64) (4) 801-3020
|
|
Domain: hamilton@csc.wcc.govt.nz PSImail: PSI%0530147000090::HAMILTON
|
|
|
|
|
|
|
|
From linux Fri Feb 7 17:03:13 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <7024-0@banjo.concert.net>; Fri, 7 Feb 1992 17:02:36 -0500
|
|
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com)
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA07554;
|
|
Fri, 7 Feb 92 17:02:08 -0500
|
|
Received: by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA20790;
|
|
Fri, 7 Feb 1992 17:02:01 -0500
|
|
Received: by ponds.UUCP (smail2.5) id AA10822; 7 Feb 92 16:40:16 EST (Fri)
|
|
To: dg-rtp!concert.net!linux-standards-request@concert.net,
|
|
linux-standards@concert.net
|
|
Subject: Re: DRAFT of File System document
|
|
Message-Id: <9202071640.AA10818@ponds.UUCP>
|
|
Date: 7 Feb 92 16:40:16 EST (Fri)
|
|
From: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers)
|
|
|
|
|
|
Shared libraries live in /shlib on ISC; and in /lib on HP/UX.
|
|
|
|
|
|
From linux Sun Feb 9 11:34:32 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <10347-0@banjo.concert.net>; Sun, 9 Feb 1992 11:33:49 -0500
|
|
Received: from uceng.UC.EDU by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA11023; Sun, 9 Feb 92 11:33:45 -0500
|
|
Received: by uceng.UC.EDU (16.6/1.34) id AA26276; Sun, 9 Feb 92 11:32:31 -0500
|
|
From: strombrg@uceng.UC.edu (Dan Stromberg)
|
|
Message-Id: <9202091632.AA26276@uceng.UC.EDU>
|
|
Subject: Re: FS layout in Linux
|
|
To: poe@daimi.aau.dk
|
|
Date: Sun, 9 Feb 92 11:32:28 EST
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: <9202061519.AA17286@bentley.daimi.aau.dk>; from "poe@daimi.aau.dk" at Feb 6, 92 4:19 pm
|
|
X-Mailer: ELM [version 2.3 PL4]
|
|
|
|
>> If we could ignore our past, something like:
|
|
>> {/,/multiuser,/multiuser/package}{/executable,/data}{,/site,/local}
|
|
>> might be nicer still, but I can't pretend to believe something that
|
|
>> idealistic would gain much acceptance.
|
|
>Ideal, hmmmph.
|
|
:-)
|
|
Isn't that just what I'd said..?
|
|
|
|
It's a bit over-different, but isn't the idea to separate the
|
|
code from the data?
|
|
|
|
>> Is there a workable alternative to #! ? It's valuable, but it's
|
|
>> a *hack*. Someday, someone should implement a #$ that scans a (optionally
|
|
>> intrascript specified) path for the proper interpreter. Or perhaps, it
|
|
>> should be incorporated into the file system, as is being done with ACL's...
|
|
>> It might make sense to tackle both at the same time, with the addition of
|
|
>> an abstraction for "whatever's associated with this file" for tar's sake.
|
|
>Ugh! #! must only accept an absolute path for the interpreter, or you open
|
|
>a can of worms, securitywise.
|
|
Well...
|
|
|
|
I wasn't all that serious about the change, though it's still something
|
|
I'd like to see.
|
|
|
|
I'm not eager to start changing all my scripts from starting with
|
|
#!/usr/local/bin/bash to wherever bash starts going. But I'd rather
|
|
not see bash stay in /usr/local/bin forever, either.
|
|
|
|
I'll end up changing it anyway. What I'd like to see, is provision
|
|
made for avoiding the same thing happening again, when some other
|
|
wonderful new interpreter gains acceptance.
|
|
|
|
I fully acknowledge the abundance of kernel's that are stuck with 32
|
|
bytes, due to the a.out stuff. It'll be a *long* time before any
|
|
benefit *might* be reaped. That doesn't mean we can't start speculating
|
|
about solutions now...
|
|
|
|
Actually, maybe such a change should go in the shell, at least until
|
|
people stop using kernels provided by people who can't share. :-)
|
|
|
|
The point of including the search path *within* the script, of course,
|
|
was to address precisely the security problem you raised, while still
|
|
providing a bit more flexibility.
|
|
|
|
>> scripts. They should be deprecated, IMO. I'd actually be pretty
|
|
>> happy to see a distributed system with present, but empty, /usr/bin
|
|
>> and /usr/lib.
|
|
>
|
|
>I don't really see anything wrong with /usr/lib and /usr/bin.
|
|
I suppose there's no getting away from them.
|
|
|
|
I'm less than completely happy with them, because they give a priviledged
|
|
status to certain programs.
|
|
|
|
Consider:
|
|
|
|
"Hm. I'm running gcc 1.40. I'd like to run gcc 2.0 now that it's out.
|
|
I've got gcc-related stuff in /usr/lib and /usr/bin Hm. gcc 2.0 wants
|
|
to go there *too*, and some of the names conflict, some don't. Well,
|
|
I guess I'll just back up {my system|those directories}, figure out
|
|
which files are used by gcc 1.40 *only*, and copy in the files for
|
|
2.0"
|
|
|
|
That's good enough, as long it's not followed by:
|
|
|
|
"Gee, gcc 2.0 isn't quite stable enough yet. But /usr/lib has changed in
|
|
more ways than just updating the compiler... Now I have to sort out what's
|
|
changed, and what hasn't... I'll want to hack up a shell script to figure
|
|
out what to keep, based on the dates, *excluding* the list of gcc 1.40
|
|
files, which I can pick out of the distribution...."
|
|
|
|
Or worse still:
|
|
|
|
"Gee, gcc 2.0 is great... but this program requires gcc 1.40 to compile...
|
|
(Viz X windows or something) I guess I'll restore 1.40 temporarily,
|
|
compile, and put gcc 2.0 back..."
|
|
|
|
Sure, it doesn't happen that often. But it's a headache when it does.
|
|
It's the avoidable headaches that I personally find the most annoying.
|
|
(Essentialy complexity I can live with, and even appreciate. Accidental
|
|
complexity, I find dehumanizing)
|
|
|
|
I'd much prefer to be able to leave both on the system at various times,
|
|
and change environment variables to indicate which I want to use for a
|
|
given compilation. I'd probably leave only one on the system, most
|
|
of the time, but for those special cases...
|
|
|
|
>> Termcap could be an app. Terminfo could be an app. gcc
|
|
>> could be an app, to make room for any other compilers that may be
|
|
>> coming. Shell-of-the-month's that aren't trusted enough for system
|
|
>> scripts, could be apps. The idea is that no piece of software is really
|
|
>> central to the system's existence. Ok, init and /bin/sh probably
|
|
>> should, though the sh is arguable.
|
|
>
|
|
>Does this mean that termcap and terminfo should be programs (applications? :-)
|
|
>or shuld they just reside in /usr/app
|
|
They'd just reside there, selbstverstandlich.
|
|
|
|
"/usr/package", or an abbreviation thereof, might be preferable.
|
|
|
|
>> Ideally, /,/bin,/etc, /lib, and /dev could be copied to a
|
|
>> (moderately sized) floppy filesystem, to get another system running
|
|
>> enough to de-tar an entire distribution from diskettes/tapes/cd-roms/
|
|
>> network, and edit some config files, or invoke some simplistic
|
|
>> installation scripts/binaries.
|
|
>Good idea.
|
|
'tanks.
|
|
|
|
>> In fact, a really nicely polished system might have two
|
|
>> password files: one for single user mode, on root, and one for multiuser,
|
|
>> on /usr somewhere, maybe /usr/etc. I'm less than happy about the
|
|
>> number of systems I've seen, that had /etc/passwd (and attendant
|
|
>> databases), outgrow their root partition. Putting just logins
|
|
>> for root, system accounts, and sysadmins in /etc/passwd (perhaps only
|
|
>> these would be allowed to log in on the console), and the bulk of
|
|
>> users in /usr/etc/passwd, would be kind of nice.
|
|
>Never heard of YP^H^H NIS?
|
|
Shrug. My Master's work has been replicating the passwd map, in a more
|
|
secure manner...
|
|
|
|
It was an offhanded idea, but it's not too far from what I've done
|
|
in my MS stuff - the root partition on our machines here are just too
|
|
small our password databases. I've put an /etc/passwd-formatted file
|
|
at /usr/local/etc on our systems, and allow remote getpwnam's against
|
|
it, but not the /etc/passwd database itself.
|
|
|
|
>> S. Egdorf has mentioned that much of the reason for UNIX's
|
|
>> lack of acceptance, is its lack of shrink-wrapped software. I support
|
|
>> his conclusion (that /site in some form, make sense, though it
|
|
>> could be replaced fully or in part, but /usr/app), but not his
|
|
>> reasoning... IMO, this is technically, and politically (I'll not get
|
|
>> started again...) a reason for UNIX's resilience, as well.
|
|
>> The fact that we don't have something as constrictive as
|
|
>> the BIOS hampering UNIX's growth, is in part a strength. POSIX
|
|
>> is testament to the flexibility, and viability, of a Better Way.
|
|
>Does anyone really think we will ever have shrik-wrapped apps. for linux??
|
|
Well...
|
|
|
|
Linux' doing a lot of the UNIX API already, you know? If UNIX gets
|
|
shrink-wrap going, it might be worth looking into for linux, in
|
|
*whatever* form.
|
|
|
|
>I view linux as a hackers system, where we can have source for everything, and
|
|
>not have to rely on shrinkwrapped binaries-only packages.
|
|
I must admit, I like the extra flexibility of packages that come in source
|
|
form. I believe that's why UNIX is out-living MS-DOS, despite predating
|
|
MS-DOS.
|
|
|
|
What I'm not crazy about, is the repetitive mapping of index to strchr and
|
|
such. I'd be perfectly happy to grab a copy of the latest raytracer off
|
|
the net, and not have to diddle any configuration parameters...
|
|
|
|
>On another note, beware of the tendency to make linux an "design by commitee"
|
|
>system. I belive that linux is as good as it is, because it was designed and
|
|
>implemented by one man (Linus). This doesn't mean that we should stop making
|
|
>contributions and extensions, as Linus can't do everything for us.
|
|
>
|
|
>Trying to forge standards at this early stage seems a bit futile to me,
|
|
>time will tell where linux goes.... (This will probably make my mailbox
|
|
>bloat with flames, Oh well..)
|
|
Ah! Politics! :-)
|
|
|
|
I don't see this as a flame; you might: I'd rather see linux guided by
|
|
a group of people who can make suggestions, without getting crazy if
|
|
something gets voted down, than a more usual committee, or even just
|
|
letting it take its course.
|
|
|
|
Given Linus' discussion with Tannenbaum on comp.os.minix, I'd he's
|
|
pretty realistic about the fact that lots of people will have lots
|
|
of different desires, with regard to Linux' future.
|
|
|
|
In fact, I'd say his choice of copyright mandates it.
|
|
|
|
> - Peter.
|
|
|
|
- Dan
|
|
|
|
|
|
From linux Sun Feb 9 20:18:11 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <10616-0@banjo.concert.net>; Sun, 9 Feb 1992 20:17:21 -0500
|
|
Received: from ux1.isu.edu ([134.50.254.5])
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA11262;
|
|
Sun, 9 Feb 92 20:17:17 -0500
|
|
Message-Id: <9202100117.AA11262@jazz.concert.net>
|
|
Received: by ux1.isu.edu (16.6/16.2) id AA00967; Sun, 9 Feb 92 18:22:00 -0700
|
|
Date: Sun, 9 Feb 92 18:22:00 -0700
|
|
From: Dan Simmons <simmdan@ux1.isu.edu>
|
|
To: linux-standards@concert.net
|
|
Subject: installing & uninstalling packages
|
|
|
|
|
|
Just a thought... Give me your reactions.
|
|
|
|
I know that this would be introducing something totally non-standard into
|
|
linux, but it seems like it might be worth doing, and I think it could be
|
|
implemented with complete or nearly complete backward compatibility.
|
|
|
|
Here it is: Add another "owner" field to each file. This field will not be
|
|
used for security at all but for additional flexibility in specifying groups
|
|
of files. So you would have, owner, group, and something we might call
|
|
"package". When you install a package on the system, you would write all the
|
|
files to disk with a unique package number. That is, the install program would
|
|
query the system for a new package number and then write that along with a
|
|
package name into some file kind of like /etc/passwd which maps the numbers to
|
|
the packages. Then you could either implement some separate commands or new
|
|
switches on old commands which would allow you to list/remove, etc. Any files
|
|
tagged with a particular package number.
|
|
|
|
I can think of several problems with this idea, but I can also see many
|
|
advantages. There are lots of people complaining about the file system
|
|
structure and the trouble of identifying which files in /usr/lib belong to
|
|
gcc-1.40 and which to gcc-2.0, and this might be a solution...
|
|
|
|
So, there it is. What do you think?
|
|
|
|
Daniel Simmons dsimmons@cs.cornell.edu, simmdan@ux1.isu.edu
|
|
-------------------------------------------------------------------------
|
|
For the Lord of hosts has planned, and who can frustrate it? And as for
|
|
His stretched-out hand, who can turn it back? -- Isaiah 14:27
|
|
|
|
From linux Tue Feb 11 08:38:35 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Subject: Draft 2 of FILE SYSTEM STRUCTURE
|
|
To: linux-standards@concert.net
|
|
Date: Tue, 11 Feb 92 8:37:23 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@concert.net>
|
|
Sender: abc@concert.net
|
|
|
|
Well, thanks to everyone for their input on Draft 1. I have marked all the
|
|
changes between Draft 1 and Draft 2 with vertical bars (|) in column 1.
|
|
|
|
Please send comments.
|
|
|
|
==============
|
|
The following is being submitted by Alan Clegg [abc@concert.net] as the
|
|
proposed standard for directory file structure under Linux.
|
|
|
|
REVISION TWO.
|
|
|
|
Complete implementation of this file structure is completely voluntary,
|
|
and will not be enforced, but will be recommended. This specification
|
|
is released as guidelines for people porting and writing software for
|
|
the Linux Operating System to allow easy software installation, upgrade, and
|
|
tailoring on already installed systems.
|
|
|
|
Root Directory:
|
|
|
|
Files:
|
|
{none defined by spec}
|
|
|
|
Directories:
|
|
| bin dev etc home lib mnt usr
|
|
|
|
Rationale:
|
|
The root directory should not be cluttered with files or
|
|
directories, and should contain no user programs.
|
|
|
|
/bin Directory:
|
|
|
|
Files:
|
|
sh init mount umount dd cat ls fsck {and as needed}
|
|
|
|
Directories:
|
|
{none defined by spec}
|
|
|
|
Rationale:
|
|
The /bin directory should contain programs that are vital
|
|
to the restoration of other file systems in the case of
|
|
a corrupting crash. No executable in /bin should require
|
|
any other file system to be mounted to execute correctly.
|
|
|
|
/dev Directory:
|
|
|
|
Files:
|
|
{device files}
|
|
|
|
Directories:
|
|
{none define by spec}
|
|
|
|
Rationale:
|
|
| Standard UNIX device files. This directory should contain
|
|
| device entries for all devices that are supported in the
|
|
| standard kernel, even if the hardware device does not exist
|
|
| on the system. Note that the distribution will have all
|
|
| device files, but they may be removed by the user upon
|
|
| system installation.
|
|
|
|
/etc Directory:
|
|
|
|
Files:
|
|
mtab passwd rc ttytab {and as needed}
|
|
|
|
Directories:
|
|
{none defined by spec}
|
|
|
|
Rationale:
|
|
Standard location of files required during system boot. Files
|
|
in this directory are usually system specific. Most will
|
|
require human intervention during system upgrade.
|
|
|
|
|/home Directory:
|
|
|
|
|
| Files:
|
|
| NONE
|
|
|
|
|
| Directories:
|
|
| {one per user excepting root}
|
|
|
|
|
| Rationale:
|
|
| Standard location of users home directories. Will most likely
|
|
| be a mounted file system once the system is up. root's home
|
|
| directory should be /.
|
|
|
|
/lib Directory:
|
|
|
|
Files:
|
|
{libraries required for system initialization}
|
|
|
|
Directories:
|
|
{none defined by spec}
|
|
|
|
Rationale:
|
|
To keep the size of the root partition small (if separate from
|
|
/usr), the files in this directory should only be ones required
|
|
by files in the root partition.
|
|
|
|
/mnt Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
Directories:
|
|
NONE
|
|
|
|
Rationale:
|
|
Standard mount point for external (transient) file systems.
|
|
Must be available for sub-system installation. Should remain
|
|
as an empty directory.
|
|
|
|
/tmp Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
Directories:
|
|
NONE
|
|
|
|
Rationale:
|
|
Temporary file space available for general program use. May
|
|
become a mounted partition upon system boot. [Minimum size?]
|
|
|
|
/usr Directory:
|
|
|
|
Files:
|
|
{none defined by spec}
|
|
|
|
Directories:
|
|
adm bin spool local lib etc man include src tmp
|
|
|
|
Rationale:
|
|
/usr is the mount point for the second major (after root)
|
|
hierarchy of file structure and is discussed in the next
|
|
section.
|
|
|
|
/usr/adm Directory:
|
|
|
|
Files:
|
|
{none defined in spec}
|
|
|
|
Directories:
|
|
{none defined in spec}
|
|
|
|
Rationale:
|
|
Location of log files and accounting information.
|
|
|
|
/usr/bin Directory:
|
|
|
|
Files:
|
|
{all executable files from standard distribution not contined
|
|
in /bin}
|
|
|
|
Directories:
|
|
{none defined in spec}
|
|
|
|
Rationale:
|
|
contains 'drop-in' executables that are considered to be
|
|
standard to the UNIX system. These files should NOT be
|
|
Linux specific, but should have the same function as their
|
|
UNIX equivalents.
|
|
|
|
/usr/etc Directory:
|
|
|
|
Files:
|
|
{none defined in spec}
|
|
|
|
Directories:
|
|
{none defined in spec}
|
|
|
|
Rationale:
|
|
contains configuration files for any files in /usr/bin. helps
|
|
to keep /etc clean and small.
|
|
|
|
/usr/spool Directory:
|
|
|
|
Files:
|
|
{none defined in spec}
|
|
|
|
Directories:
|
|
uucp mail
|
|
|
|
Rationale:
|
|
containes spool files for mail, printing, uucp transfer, etc.
|
|
May be a mount point for another volume.
|
|
|
|
/usr/local Directory:
|
|
|
|
Files:
|
|
| NONE
|
|
|
|
Directories:
|
|
bin lib etc man src
|
|
|
|
Rationale:
|
|
contains files local to the specific system. will not be
|
|
modified by upgrade process.
|
|
|
|
/usr/lib Directory:
|
|
|
|
Files:
|
|
libc.a crt0.s {and as needed}
|
|
|
|
Directories:
|
|
{none defined in spec}
|
|
|
|
Rationale:
|
|
location for library files required for multi-user system
|
|
operation. This is the directory where program libraries
|
|
should reside.
|
|
|
|
/usr/man Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
Directories:
|
|
man1 man2 man3 man4 man5 man6 man7 man8
|
|
|
|
Rationale:
|
|
Contains manual pages for programs that are standard with
|
|
Linux.
|
|
|
|
/usr/include Directory:
|
|
|
|
Files:
|
|
{programmers include files}
|
|
|
|
Directories:
|
|
{as needed}
|
|
|
|
Rationale:
|
|
Standard place for system include files.
|
|
|
|
/usr/src Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
Directories:
|
|
| bin lib linux usr.bin usr.lib
|
|
|
|
Rationale:
|
|
Contains source code for all applications in the release.
|
|
/usr/src/linux contains directories required for kernel builds.
|
|
|
|
/usr/tmp Directory:
|
|
|
|
Files:
|
|
NONE
|
|
|
|
|
|
Directories:
|
|
NONE
|
|
|
|
Rationale:
|
|
Used as additional scratch space for programs. If /tmp is
|
|
a mounted file system, /usr/tmp may be a symbolic link to
|
|
/tmp.
|
|
|
|
==============REMOVED==============
|
|
/usr/linux Directory:
|
|
|
|
Rationale for removal:
|
|
No clean definition of 'linux specific'. All binaries,
|
|
libraries, and etc will reside below / and /usr.
|
|
|
|
/usr/users Directory:
|
|
|
|
Rationale for removal:
|
|
Moved to /home.
|
|
==============REMOVED==============
|
|
|
|
Please feel free to comment on these ideas, and let me know what you think.
|
|
==============
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux Tue Feb 11 09:08:41 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <19034-0@banjo.concert.net>; Tue, 11 Feb 1992 09:07:49 -0500
|
|
Received: from sumax.seattleu.edu
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA24965;
|
|
Tue, 11 Feb 92 09:07:45 -0500
|
|
Received: by sumax.seattleu.edu id AA24326 (5.65a/IDA-1.4.2
|
|
for linux-standards@concert.net); Tue, 11 Feb 92 06:10:22 -0800
|
|
Date: Tue, 11 Feb 92 06:10:22 -0800
|
|
From: Chuck Boyer <boyer@sumax.seattleu.edu>
|
|
Message-Id: <9202111410.AA24326@sumax.seattleu.edu>
|
|
To: abc@concert.net, linux-standards@concert.net
|
|
Subject: Re: Draft 2 of FILE SYSTEM STRUCTURE
|
|
|
|
Fine, vote one for 'yes'. Make it so. Then, when someone distributes
|
|
something that uses dirs differently they can list such in the Readme
|
|
file for compilation.
|
|
chuck
|
|
|
|
From linux Tue Feb 11 09:29:32 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <184-0@banjo.concert.net>; Tue, 11 Feb 1992 09:28:04 -0500
|
|
Received: from daimi.aau.dk by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA25277; Tue, 11 Feb 92 09:27:55 -0500
|
|
Received: from bentley.daimi.aau.dk by daimi.aau.dk
|
|
with SMTP (5.61++/IDA-1.2.8) id AA09800;
|
|
Tue, 11 Feb 92 15:26:26 +0100
|
|
Received: by bentley.daimi.aau.dk (5.64/1.34) id AA06465;
|
|
Tue, 11 Feb 92 15:26:17 +0100
|
|
Date: Tue, 11 Feb 92 15:26:17 +0100
|
|
From: tthorn@daimi.aau.dk
|
|
Message-Id: <9202111426.AA06465@bentley.daimi.aau.dk>
|
|
To: abc@concert.net
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: Alan B Clegg's message of Tue, 11 Feb 92 8:37:23 EST <9202111337.AA08398@daimi.aau.dk>
|
|
Subject: Draft 2 of FILE SYSTEM STRUCTURE
|
|
|
|
YES! It's just right. Only remark: aren't we missing cat[1-8] in /usr/man?
|
|
|
|
/Tommy
|
|
|
|
From linux Tue Feb 11 16:59:56 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <3434-0@banjo.concert.net>; Tue, 11 Feb 1992 16:59:23 -0500
|
|
Received: from stolaf.edu (nic.stolaf.edu)
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA03712;
|
|
Tue, 11 Feb 92 16:59:19 -0500
|
|
Received: from loki2.cs.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA14534;
|
|
Tue, 11 Feb 92 15:59:09 CST
|
|
Date: Tue, 11 Feb 92 15:59:09 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9202112159.AA14534@stolaf.edu>
|
|
Received: by loki2.cs.stolaf.edu (4.1/SMI-4.1) id AA04011;
|
|
Tue, 11 Feb 92 15:59:09 CST
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: Alan B Clegg's message of Tue, 11 Feb 92 8:37:23 EST <9202111342.AA00548@stolaf.edu>
|
|
Subject: Draft 2 of FILE SYSTEM STRUCTURE
|
|
|
|
I vote yes on the file system structure as proposed.
|
|
|
|
I don't particularily like /usr/src/usr.{bin,lib} (I would prefer
|
|
/usr/src/usr/{bin,lib}, but I didn't get around to bringing it up in
|
|
our discussion, so I'll be quiet :-)
|
|
|
|
I also don't like /usr/tmp & /tmp as separate directories at all. I
|
|
think that they should be links, one way or the other, preferably to a
|
|
fs other than root.
|
|
|
|
I agree with both removals.
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
I don't do .sig's.
|
|
|
|
From linux Tue Feb 11 18:37:33 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <3699-0@banjo.concert.net>; Tue, 11 Feb 1992 18:36:32 -0500
|
|
Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA04493; Tue, 11 Feb 92 18:36:30 -0500
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA01539;
|
|
Tue, 11 Feb 92 18:36:23 -0500
|
|
Date: Tue, 11 Feb 92 18:36:23 -0500
|
|
From: tytso@ATHENA.MIT.edu (Theodore Ts'o)
|
|
Message-Id: <9202112336.AA01539@tsx-11.MIT.EDU>
|
|
To: johnsonm@stolaf.edu
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: Michael K. Johnson's message of Tue, 11 Feb 92 15:59:09 CST, <9202112159.AA14534@stolaf.edu>
|
|
Subject: Re: Draft 2 of FILE SYSTEM STRUCTURE
|
|
Reply-To: tytso@athena.mit.edu
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
Date: Tue, 11 Feb 92 15:59:09 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
|
|
I also don't like /usr/tmp & /tmp as separate directories at all. I
|
|
think that they should be links, one way or the other, preferably to a
|
|
fs other than root.
|
|
|
|
No, I think they need to be different. The big difference is that /tmp
|
|
gets cleared on reboot, and /usr/tmp does not. So for example, if your
|
|
machine crashes while you are working, emacs autosave files (which in
|
|
/usr/tmp) don't get deleted. However if you are using a networked
|
|
authentication system, such as Kerberos, you would want the
|
|
cryptographic information proving your identity to be stored in /tmp,
|
|
which would be deleted upon reboot. Other temporary files which are
|
|
used by processes (like gcc) also put their files in /tmp, and they also
|
|
should be deleted upon reboot.
|
|
|
|
|
|
All in all, I like "Draft 2 of the FILE SYSTEM STRUCTURE". My only one
|
|
nit is with /homes, which I think is a bad idea. I would much rather
|
|
prefer /usr/homes, so that if you have an extra partition, you can mount
|
|
it over /usr/homes, but if you don't have an extra partition to spare
|
|
(and you still want the root to be small), you can leave it in the /usr
|
|
partition. By putting that directory in /homes, you remove that choice.
|
|
|
|
It's not a big deal though. I will probably deal with this problem by
|
|
installing a sym link from /homes to /usr/homes. Where home directories
|
|
"really" are isn't very important anyway, since no program should be
|
|
depending on their location.
|
|
|
|
- Ted
|
|
|
|
From linux Wed Feb 12 11:05:20 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Subject: Draft moved to Final
|
|
To: linux-standards@concert.net
|
|
Date: Wed, 12 Feb 92 11:04:46 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@concert.net>
|
|
Sender: abc@concert.net
|
|
|
|
Well, with everyone not responding taken as a "HOORAY, IT LOOKS *GREAT*",
|
|
we have 98% agreement with the Draft File System document.
|
|
|
|
I suggest that we move it from Draft into Final standard, and send it to
|
|
linux-activists and alt.os.linux.
|
|
|
|
Any seconds?
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux Wed Feb 12 11:45:18 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <7835-0@banjo.concert.net>; Wed, 12 Feb 1992 11:44:16 -0500
|
|
Received: from stolaf.edu (nic.stolaf.edu)
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA10421;
|
|
Wed, 12 Feb 92 11:44:09 -0500
|
|
Received: from amcl11.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA05685;
|
|
Wed, 12 Feb 92 10:44:01 CST
|
|
Date: Wed, 12 Feb 92 10:44:01 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9202121644.AA05685@stolaf.edu>
|
|
Received: by amcl11.math.stolaf.edu (4.1/SMI-4.1) id AA04828;
|
|
Wed, 12 Feb 92 10:44:00 CST
|
|
To: linux-standards@concert.net
|
|
In-Reply-To: Alan B Clegg's message of Wed, 12 Feb 92 11:04:46 EST <9202121610.AA05214@stolaf.edu>
|
|
Subject: Draft moved to Final
|
|
|
|
Well, with everyone not responding taken as a "HOORAY, IT LOOKS *GREAT*",
|
|
we have 98% agreement with the Draft File System document.
|
|
|
|
I suggest that we move it from Draft into Final standard, and send it to
|
|
linux-activists and alt.os.linux.
|
|
|
|
Any seconds?
|
|
|
|
I second the motion :-)
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
I don't do .sig's.
|
|
|
|
|
|
From linux Wed Feb 12 12:36:42 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <8613-0@banjo.concert.net>; Wed, 12 Feb 1992 12:35:30 -0500
|
|
Received: from sumax.seattleu.edu
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA10825;
|
|
Wed, 12 Feb 92 12:35:26 -0500
|
|
Received: by sumax.seattleu.edu id AA15117 (5.65a/IDA-1.4.2
|
|
for linux-standards@concert.net); Wed, 12 Feb 92 09:38:03 -0800
|
|
Date: Wed, 12 Feb 92 09:38:03 -0800
|
|
From: Chuck Boyer <boyer@sumax.seattleu.edu>
|
|
Message-Id: <9202121738.AA15117@sumax.seattleu.edu>
|
|
To: abc@concert.net, linux-standards@concert.net
|
|
Subject: Re: Draft moved to Final
|
|
|
|
Make it so.
|
|
|
|
From linux Wed Feb 12 13:03:49 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <8822-0@banjo.concert.net>; Wed, 12 Feb 1992 13:02:57 -0500
|
|
Received: from sun2.nsfnet-relay.ac.uk
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA11255;
|
|
Wed, 12 Feb 92 13:02:36 -0500
|
|
Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk
|
|
via JANET with NIFTP id <10909-0@sun2.nsfnet-relay.ac.uk>;
|
|
Wed, 12 Feb 1992 13:25:00 +0000
|
|
Message-Id: <12 Feb 92 12:10:57 GMT ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Wed, 12 Feb 92 12:10:57 GMT
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
Myname: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@concert.net>
|
|
Subject: Comments on Draft 2
|
|
|
|
|
|
1) I am a little unhappy about having init in /bin, since no
|
|
user -- not even root -- needs to access it. Should this
|
|
be in lib?
|
|
|
|
2) I do not think root's home directory should be in /, since
|
|
this means that / tends to accumulate .exrc, .profile, .bashrc,
|
|
.kermrc, etc. Also there are utilities that write files in
|
|
your home directory; these should not write to /.
|
|
|
|
3) What goes in /lib? The draft says 'libraries required for
|
|
system initialisation'. I presume this is either shared
|
|
libraries (in which case libc.a belongs here, not in /usr/lib)
|
|
or libraries needed to reconfigure the kernel (in which case,
|
|
/lib does not seem as approproate as /usr/etc or /etc).
|
|
|
|
4) The draft says that /usr/lib should contain crt0.s. Presumably
|
|
this is an error for crt0.o.
|
|
|
|
Generally I think the draft is good, providing clear reasons for
|
|
simple choices.
|
|
|
|
A. V. Le Blanc
|
|
University of Manchester
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux Wed Feb 12 17:33:19 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <11556-0@banjo.concert.net>; Wed, 12 Feb 1992 17:32:46 -0500
|
|
Received: from stolaf.edu (nic.stolaf.edu)
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA19615;
|
|
Wed, 12 Feb 92 17:32:41 -0500
|
|
Received: from loki6.cs.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA06770;
|
|
Wed, 12 Feb 92 16:32:32 CST
|
|
Date: Wed, 12 Feb 92 16:32:32 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9202122232.AA06770@stolaf.edu>
|
|
Received: by loki6.cs.stolaf.edu (4.1/SMI-4.1) id AA01914;
|
|
Wed, 12 Feb 92 16:32:26 CST
|
|
To: linux-standards@concert.net
|
|
In-Reply-To: LeBlanc@manchester-computing-centre.ac.uk's message of Wed, 12 Feb 92 12:10:57 GMT <12 Feb 92 12:10:57 GMT ZLSIIAL@UK.AC.MCC.CMS>
|
|
Subject: Comments on Draft 2
|
|
|
|
Date: Wed, 12 Feb 92 12:10:57 GMT
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
Myname: A. V. Le Blanc
|
|
|
|
|
|
1) I am a little unhappy about having init in /bin, since no
|
|
user -- not even root -- needs to access it. Should this
|
|
be in lib?
|
|
|
|
I don't think that we want any executables in /lib. if you don't want
|
|
it in bin, you could put it in /etc, but we are trying to keep
|
|
executables out of /etc in the standard, if I recall corectly. So
|
|
/bin makes sense to me. And it doesn't cost _that_ much search time,
|
|
and when we get ffs and other advanced fs's that do non-linear
|
|
searches, it will essentially be a moot point. And it shouldn't be
|
|
that much longer till ffs, so let's design around ffs not the v7 fs.
|
|
|
|
2) I do not think root's home directory should be in /, since
|
|
this means that / tends to accumulate .exrc, .profile, .bashrc,
|
|
.kermrc, etc. Also there are utilities that write files in
|
|
your home directory; these should not write to /.
|
|
|
|
Correct me if I am wrong (not that I am worried that people wouldn't...
|
|
:-) but root, the user, should not have such files. once we have
|
|
init, we want to spend as little time logged in as root as possible,
|
|
and then usually su'd to root.
|
|
|
|
3) What goes in /lib? The draft says 'libraries required for
|
|
system initialisation'. I presume this is either shared
|
|
libraries (in which case libc.a belongs here, not in /usr/lib)
|
|
or libraries needed to reconfigure the kernel (in which case,
|
|
/lib does not seem as approproate as /usr/etc or /etc).
|
|
|
|
Good point, I think. Unless we staticly link everything in /bin, we
|
|
need the shared libes in the root fs. ooh, yuk. Anyone have a better
|
|
solution? I'd hate to go with staticly linked /sbin and dynamically
|
|
linked /bin...
|
|
|
|
Of course, I am probably missing something entirely...
|
|
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
Look, Ma, no .sig!
|
|
|
|
From linux Thu Feb 13 04:01:53 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <13383-0@banjo.concert.net>; Thu, 13 Feb 1992 04:00:57 -0500
|
|
Received: from sun2.nsfnet-relay.ac.uk
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA21143;
|
|
Thu, 13 Feb 92 04:00:51 -0500
|
|
Message-Id: <9202130900.AA21143@jazz.concert.net>
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <5478-0@sun2.nsfnet-relay.ac.uk>; Thu, 13 Feb 1992 08:33:17 +0000
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa14210;
|
|
13 Feb 92 8:41 GMT
|
|
Date: Thu, 13 Feb 92 08:38:47 +0000
|
|
From: db1@ukc.ac.uk
|
|
To: linux-standards@concert.net
|
|
Subject: Root home in /
|
|
|
|
Root home is usually in / since any other directory may be mounted
|
|
Therefore, If you want to do admin with a broken disk or handle
|
|
your disks in Single user you need root to be in /
|
|
|
|
BTW. You can use su from ordinary user if you want to be root and
|
|
stiil retain the current home
|
|
( su - ) Changes HOME also, su alone leave the current.
|
|
|
|
Damiano
|
|
|
|
From linux Thu Feb 13 04:25:31 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <13475-0@banjo.concert.net>; Thu, 13 Feb 1992 04:24:26 -0500
|
|
Received: from ebr.eb.ele.tue.nl by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA21176; Thu, 13 Feb 92 04:24:21 -0500
|
|
Received: by ebr.eb.ele.tue.nl (5.65b/1.53) id AA08950;
|
|
Thu, 13 Feb 92 10:23:32 +0100
|
|
Date: Thu, 13 Feb 92 10:23:32 +0100
|
|
From: volf@eb.ele.tue.nl (Frank Volf)
|
|
Message-Id: <9202130923.AA08950@ebr.eb.ele.tue.nl>
|
|
To: johnsonm@stolaf.edu, linux-standards@concert.net
|
|
Subject: Re: Comments on Draft 2
|
|
|
|
|
|
Hi,
|
|
|
|
You johnsonm@stolaf.edu (Michael K. Johnson) wrote:
|
|
|
|
> 1) I am a little unhappy about having init in /bin, since no
|
|
> user -- not even root -- needs to access it. Should this
|
|
> be in lib?
|
|
>
|
|
>I don't think that we want any executables in /lib. if you don't want
|
|
>it in bin, you could put it in /etc, but we are trying to keep
|
|
>executables out of /etc in the standard, if I recall corectly. So
|
|
^^^^^^^^^^^
|
|
|
|
Why??? I always thought most of the man (8) commands should be in
|
|
/etc (or /usr/etc). At least at our site it does.
|
|
I think it is not a good idea to have any commands in /bin which
|
|
are not intended for ordinary users. These commands include
|
|
mknod, mkswap, fsck, mount, umount and other stuff we don't have yet
|
|
(reboot, lpc for example).
|
|
|
|
I think that all those commands intended for system administration (and
|
|
not useful for the other users) should go into /etc or /usr/etc. Ordinary
|
|
users should not have /etc in their search path (although we can't prevent
|
|
them from doing so). Root should have /etc in the very beginning of its
|
|
search path.
|
|
|
|
Init should not be in /bin. It is not an executable in the sense it can
|
|
be run by any user (including root). /etc/init would be a good idea (at
|
|
our side it is). If /etc/init is a very big problem (which isn't I think)
|
|
it should go to /lib (there are executables in /usr/lib (for example atrun,
|
|
cpp etc.) so why not in /lib??? (although the best place is /etc)
|
|
|
|
Best regards, Frank
|
|
|
|
------------------------------------------------------------------------
|
|
- Frank Volf INTERNET : volf@eb.ele.tue.nl -
|
|
- Eindhoven University of Technology -
|
|
- Digital Systems Group, Room EH10.16 -
|
|
- P.O. 513, -
|
|
- 5600 MB Eindhoven, The Netherlands -
|
|
------------------------------------------------------------------------
|
|
|
|
From linux Thu Feb 13 09:14:58 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <14484-0@banjo.concert.net>; Thu, 13 Feb 1992 09:13:35 -0500
|
|
Received: from sage.cc.purdue.edu
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA22955;
|
|
Thu, 13 Feb 92 09:13:33 -0500
|
|
Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA02565;
|
|
Thu, 13 Feb 92 09:13:25 -0500
|
|
From: asg@sage.cc.purdue.edu (The Grand Master)
|
|
Message-Id: <9202131413.AA02565@sage.cc.purdue.edu>
|
|
Subject: Re: Comments on Draft 2
|
|
To: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Date: Thu, 13 Feb 92 9:13:23 EST
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: <9202122232.AA06770@stolaf.edu>; from "Michael K. Johnson" at Feb 12, 92 4:32 pm
|
|
Needs: Your attention
|
|
Organization: Fraternal Order of Red-haired Milkmaids
|
|
|
|
In the unforgettable words of Michael K. Johnson:
|
|
->
|
|
-> Date: Wed, 12 Feb 92 12:10:57 GMT
|
|
-> From: LeBlanc@manchester-computing-centre.ac.uk
|
|
-> Myname: A. V. Le Blanc
|
|
->
|
|
->I don't think that we want any executables in /lib. if you don't want
|
|
->it in bin, you could put it in /etc, but we are trying to keep
|
|
->executables out of /etc in the standard, if I recall corectly. So
|
|
->/bin makes sense to me. And it doesn't cost _that_ much search time,
|
|
->and when we get ffs and other advanced fs's that do non-linear
|
|
->searches, it will essentially be a moot point. And it shouldn't be
|
|
->that much longer till ffs, so let's design around ffs not the v7 fs.
|
|
|
|
Well.......
|
|
I do not understand this fascination with keeping executables out
|
|
of etc. It is normal, traditional UNIX convention for mount, umount,
|
|
mknod, mkfs, shutdown, etc to be in /etc (no pun intended). I think
|
|
it should be done that way.
|
|
->
|
|
-> 2) I do not think root's home directory should be in /, since
|
|
-> this means that / tends to accumulate .exrc, .profile, .bashrc,
|
|
-> .kermrc, etc. Also there are utilities that write files in
|
|
-> your home directory; these should not write to /.
|
|
->
|
|
->Correct me if I am wrong (not that I am worried that people wouldn't...
|
|
->:-) but root, the user, should not have such files. once we have
|
|
->init, we want to spend as little time logged in as root as possible,
|
|
->and then usually su'd to root.
|
|
|
|
root still needs .profile, .exrc, and .bashrc. When you log in as root
|
|
(those seldom occasions) you want your environment set up. And when you
|
|
su to root, you want .bashrc to set some things up for you (maybe an
|
|
alias like alias rm='rm -i'). In either case, you want .exrc (or .emacs
|
|
if you prefer emacs) so that when root edits files, your normal (or
|
|
some special root) macros are available.
|
|
->
|
|
|
|
Bruce
|
|
|
|
--
|
|
Disclaimer: The aka "The Grand Master" Courtesy of Bruce Varney
|
|
is due to an inside joke among aka -> The Grand Master
|
|
myself and some old friends - asg@sage.cc.purdue.edu
|
|
so please don't take offense PUCC
|
|
|
|
From linux Thu Feb 13 11:43:05 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <15542-0@banjo.concert.net>; Thu, 13 Feb 1992 11:42:30 -0500
|
|
Received: from engr.uark.edu by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA25141; Thu, 13 Feb 92 11:42:28 -0500
|
|
Received: by engr.uark.edu (/\==/\ Smail3.1.25.1 #25.3)
|
|
id <m0lEjWN-00014XC@engr.uark.edu>; Thu, 13 Feb 92 10:42 CST
|
|
Message-Id: <m0lEjWN-00014XC@engr.uark.edu>
|
|
Date: Thu, 13 Feb 92 10:42 CST
|
|
From: dws@engr.uark.edu (David W. Summers)
|
|
To: linux-standards@concert.net
|
|
Subject: Re: Comments on Draft 2
|
|
|
|
I've been watching the debate about where to put Admin files and executables.
|
|
|
|
What I would like is to have the executables either in /etc/bin or /usr/etc
|
|
and the admin files themselves in /etc.
|
|
|
|
Someone mentioned that they "didn't understand this fascination with keeping
|
|
executables out of etc."
|
|
|
|
Well, I would like to keep them out, because sometimes it is confusing
|
|
(even to Sys. Admin. types like me! :-) whether or not a file (just by looking
|
|
at the file name) is supposed to be an executable or a data file). I know,
|
|
you can "ls -l" and see, but I like the separation of data files and executables
|
|
like we normally have in other directories.
|
|
|
|
I agree there should probably not be any executables in /lib or /usr/lib, but
|
|
then again, we need somewhere to put that stuff. I think that many (most?)
|
|
times things like that should go in /etc/bin or /usr/etc.
|
|
|
|
As to where root's home should go, how about "/root" ????
|
|
|
|
- David Summers
|
|
|
|
From linux Thu Feb 13 13:14:04 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <15990-0@banjo.concert.net>; Thu, 13 Feb 1992 13:13:28 -0500
|
|
Received: from sage.cc.purdue.edu
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA26925;
|
|
Thu, 13 Feb 92 13:13:25 -0500
|
|
Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA03003;
|
|
Thu, 13 Feb 92 13:13:16 -0500
|
|
From: asg@sage.cc.purdue.edu (The Grand Master)
|
|
Message-Id: <9202131813.AA03003@sage.cc.purdue.edu>
|
|
Subject: Re: Comments on Draft 2
|
|
To: dws@engr.uark.edu (David W. Summers)
|
|
Date: Thu, 13 Feb 92 13:13:15 EST
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: <m0lEjWN-00014XC@engr.uark.edu>; from "David W. Summers" at Feb 13, 92 10:42 am
|
|
Needs: Your attention
|
|
Organization: Fraternal Order of Red-haired Milkmaids
|
|
|
|
In the unforgettable words of David W. Summers:
|
|
->
|
|
->I've been watching the debate about where to put Admin files and executables.
|
|
->
|
|
->What I would like is to have the executables either in /etc/bin or /usr/etc
|
|
->and the admin files themselves in /etc.
|
|
->
|
|
->Someone mentioned that they "didn't understand this fascination with keeping
|
|
->executables out of etc."
|
|
->
|
|
->Well, I would like to keep them out, because sometimes it is confusing
|
|
->(even to Sys. Admin. types like me! :-) whether or not a file (just by looking
|
|
->at the file name) is supposed to be an executable or a data file). I know,
|
|
->you can "ls -l" and see, but I like the separation of data files and executables
|
|
->like we normally have in other directories.
|
|
|
|
Try "ls -F". Files in /etc are ones that are needed for basic system
|
|
administration, etc. This is normal, and there is no reason to change it.
|
|
Do you yet another directory for shell scripts? They are different from
|
|
binaries, and yet different from data files as well. Maybe we
|
|
should have another directory that just holds passwd and group. They
|
|
are different from utmp or mtab. You can carry division too far (which
|
|
you are doing). I am sure there are shell scripts (or even c-programs)
|
|
that have /etc/{some normal system admin command} in them. Do *YOU* want
|
|
to have to convert all those??
|
|
->
|
|
->I agree there should probably not be any executables in /lib or /usr/lib, but
|
|
->then again, we need somewhere to put that stuff. I think that many (most?)
|
|
->times things like that should go in /etc/bin or /usr/etc.
|
|
|
|
THERE ARE EXECUTABLES IN /usr/lib. WHAT DO YOU THING cpp IS???????
|
|
->
|
|
->As to where root's home should go, how about "/root" ????
|
|
|
|
No. / is apropriate. That is the whole purpose of calling the user root.
|
|
|
|
|
|
Bruce
|
|
--
|
|
Disclaimer: The aka "The Grand Master" Courtesy of Bruce Varney
|
|
is due to an inside joke among aka -> The Grand Master
|
|
myself and some old friends - asg@sage.cc.purdue.edu
|
|
so please don't take offense PUCC
|
|
|
|
From linux Thu Feb 13 14:25:45 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <17103-0@banjo.concert.net>; Thu, 13 Feb 1992 14:24:26 -0500
|
|
Received: from engr.uark.edu by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA28236; Thu, 13 Feb 92 14:24:22 -0500
|
|
Received: by engr.uark.edu (/\==/\ Smail3.1.25.1 #25.3)
|
|
id <m0lEm4B-00014XC@engr.uark.edu>; Thu, 13 Feb 92 13:25 CST
|
|
Message-Id: <m0lEm4B-00014XC@engr.uark.edu>
|
|
Date: Thu, 13 Feb 92 13:25 CST
|
|
From: dws@engr.uark.edu (David W. Summers)
|
|
To: linux-standards@concert.net
|
|
Subject: Standards Directories
|
|
|
|
Linuxers:
|
|
|
|
Also, in the BSD distribution, I noticed some /usr/include/path.h files.
|
|
|
|
If we would define common (standardized) '#define's, then we could just
|
|
reference those defines in all the new programs and they would go where
|
|
YOU want them!
|
|
|
|
Comments? Is this already being done?
|
|
|
|
- David Summers
|
|
|
|
From linux Thu Feb 13 15:56:24 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <598-0@banjo.concert.net>; Thu, 13 Feb 1992 15:55:35 -0500
|
|
Received: from Kodak.COM by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA29651; Thu, 13 Feb 92 15:55:30 -0500
|
|
Received: from kodak.kodak.com by Kodak.COM (5.61+/2.1-Eastman Kodak)
|
|
id AA06159; Thu, 13 Feb 92 15:54:33 -0500
|
|
Reply-To: nobody@Kodak.com
|
|
Received: from sisd.kodak.com by kodak.Kodak.COM (4.1/SMI-4.1) id AA18837;
|
|
Thu, 13 Feb 92 15:55:08 EST
|
|
Received: from acorn.UUCP by sisd.kodak.com (4.1/SMI-4.x_sisd_main_v1)
|
|
id AA18048; Thu, 13 Feb 92 15:53:46 EST
|
|
Received: from flash.acorn by acorn (4.1/SMI-4.0) id AA09661;
|
|
Thu, 13 Feb 92 15:50:52 EST
|
|
Received: by flash.acorn (4.1/SMI-4.1) id AA15641; Thu, 13 Feb 92 15:50:50 EST
|
|
Date: Thu, 13 Feb 92 15:50:50 EST
|
|
From: obz@sisd.sisd.Kodak.com (Orest Zborowski)
|
|
Message-Id: <9202132050.AA15641@flash.acorn>
|
|
To: linux-standards@concert.net
|
|
Subject: standard directory hierarchy
|
|
|
|
i have a few thoughts on this directory issue:
|
|
|
|
1) linux is supposed to support posix - it does a pretty good job supporting
|
|
posix.1, the os interface layer. there is a posix.2 which describes a bunch
|
|
of utilities available from the shell. i'm not sure it has produced any
|
|
standards document, but i do believe i've read about its progress in
|
|
communications of the acm, and in ieee computer. this should be the
|
|
authority.
|
|
|
|
2) following svr4 standards seems to be the logical next step. svr4 is truly
|
|
posix compliant and posix seems to lean heavily to sysv for certain things
|
|
like directory structure. bsd, especially sunos, is also moving towards
|
|
svr4.
|
|
|
|
3) its true, certain applications have /lib/cpp burned into them and its gonna
|
|
be difficult to remove it. even things like the standards can't remove that
|
|
stain; you can move it (like sunos, which symlinks everything), but you can't
|
|
remove it.
|
|
|
|
i think its a little naive to believe that we can come up with some special
|
|
directory hierarchy which is the be-all and end-all of structures, and then
|
|
we should change all these programs to conform. if you like, you can make
|
|
whatever changes you desire, like using symlinks to keep a partition readonly,
|
|
or shareable; changing the entry in /etc/passwd and make roots directory
|
|
/root, etc. for the standard distribution i would choose to make as few
|
|
changes from existing standards or existing implementations as possible.
|
|
|
|
zorst
|
|
obz@sisd.kodak.com
|
|
|
|
From linux Thu Feb 13 18:20:17 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP)
|
|
id <1467-0@banjo.concert.net>; Thu, 13 Feb 1992 18:19:30 -0500
|
|
Received: from amcl3.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA02138;
|
|
Thu, 13 Feb 92 17:19:20 CST
|
|
Date: Thu, 13 Feb 92 17:19:20 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9202132319.AA02138@stolaf.edu>
|
|
Received: by amcl3.math.stolaf.edu (4.1/SMI-4.1) id AA01505;
|
|
Thu, 13 Feb 92 17:19:19 CST
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: POSIX
|
|
|
|
Does everyone know that the POSIX standards are available for ftp?
|
|
|
|
they are at research.att.com in the posix directory. Instead
|
|
of arguing about what they say, we can go look. login netlib,
|
|
password ident. You will want to be aware that the whole thing is
|
|
several megs, but it is freely available. If you are insane enough to
|
|
want to print it out, it is over 1100 pages.
|
|
|
|
You can get text or ps versions: I have been warned that the ps
|
|
versions (many megs) are not the best postscript, but I cannot verify
|
|
this, since I felt that the most useful thing would be the text
|
|
version. You also have the option of getting the whole thing in one
|
|
chunk or getting all the little pieces and only getting what you need.
|
|
This is facillitated by the availability of a table of contents.
|
|
|
|
this is the file /netlib/posix/index:research.att.com
|
|
|
|
-----8<-----
|
|
|
|
This directory tree contains some working papers for POSIX committees
|
|
operating under the auspices of the IEEE. These are being made available
|
|
with the kind permission of both the IEEE and the working groups involved.
|
|
Suggestions or comments should be sent to Hal Jespersen, TCOS SEC Vice
|
|
Chair: hlj@posix.com. Information about the POSIX or IEEE standards
|
|
process can be obtained from Jim Isaak, TCOS SEC Chair: isaak@decvax.dec.com.
|
|
|
|
Online access to these documents is an experimental procedure. Only a
|
|
small subset of documents will be immediately available, but the number
|
|
should increase over time.
|
|
|
|
The directory structure is roughly:
|
|
|
|
committee/draftnumber/file Draft documents
|
|
meeting/file Meeting announcements and agendas
|
|
minutes/file Meeting minutes
|
|
|
|
Drafts are often available in both plain text and a page layout
|
|
language, most often PostScript. The following committees have drafts
|
|
available:
|
|
|
|
p1003.2
|
|
p1003.0
|
|
p1003.2a
|
|
p1003.2b
|
|
|
|
There is also a directory of interest to POSIX technical editors:
|
|
|
|
teched
|
|
|
|
-----8<-----
|
|
|
|
You can look around from there.
|
|
|
|
Have fun, and I hope that this helps.
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
I don't do .sig's.
|
|
|
|
From linux Thu Feb 13 18:26:00 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <1514-0@banjo.concert.net>; Thu, 13 Feb 1992 18:25:28 -0500
|
|
Received: from ncnoc.concert.net by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA01454; Thu, 13 Feb 92 18:25:26 -0500
|
|
Received: from stolaf.edu (nic.stolaf.edu)
|
|
by ncnoc.concert.net (5.59/tas-concert/6-19-91) id AA10108;
|
|
Thu, 13 Feb 92 18:25:23 -0500
|
|
Received: from amcl3.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA02222;
|
|
Thu, 13 Feb 92 17:24:01 CST
|
|
Date: Thu, 13 Feb 92 17:24:01 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9202132324.AA02222@stolaf.edu>
|
|
Received: by amcl3.math.stolaf.edu (4.1/SMI-4.1) id AA01514;
|
|
Thu, 13 Feb 92 17:24:01 CST
|
|
To: linux-standards@concert.net
|
|
In-Reply-To: Frank Volf's message of Thu, 13 Feb 92 10:23:32 +0100 <9202130923.AA08950@ebr.eb.ele.tue.nl>
|
|
Subject: Comments on Draft 2
|
|
|
|
I, johnsonm@stolaf.edu, said
|
|
>it in bin, you could put it in /etc, but we are trying to keep
|
|
>executables out of /etc in the standard, if I recall corectly. So
|
|
^^^^^^^^^^^
|
|
disengage brain, engage fingers.... BEEP BEEP BEEP wrong. thanks
|
|
for corrections...
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
I don't do .sig's.
|
|
|
|
From linux Thu Feb 13 22:20:48 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <2333-0@banjo.concert.net>; Thu, 13 Feb 1992 22:20:10 -0500
|
|
Received: from sumax.seattleu.edu
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA02013;
|
|
Thu, 13 Feb 92 22:20:07 -0500
|
|
Received: by sumax.seattleu.edu id AA12305 (5.65a/IDA-1.4.2
|
|
for linux-standards@concert.net); Thu, 13 Feb 92 19:22:36 -0800
|
|
Date: Thu, 13 Feb 92 19:22:36 -0800
|
|
From: Chuck Boyer <boyer@sumax.seattleu.edu>
|
|
Message-Id: <9202140322.AA12305@sumax.seattleu.edu>
|
|
To: johnsonm@stolaf.edu, linux-standards@concert.net
|
|
Subject: Re: Comments on Draft 2
|
|
|
|
Well, it seems to me, that with 3 or 4 major 'basic' machines (SUN, PC
|
|
clone 386, 'old' unix users, 'new' unix users) that there should be
|
|
agreed upon by a vote which set of standards of a dir tree structure
|
|
that should be set. Pure democratic vote, where the majority percentage
|
|
wins, first. Second, then we will be 'set.' Then posters of ported or
|
|
new software will have to state whether their libs, etc. will look for
|
|
things in the compile/build/make process in 'standard' or 'non-standard'
|
|
format. Then it is easy to post formulas for making the thing executable.
|
|
There will then be people who refuse, for one reason or another, to change
|
|
their setup and can just link away, set up standard links, etc.
|
|
But, this should be set up via the Posix standard at first. The discussion
|
|
has to stop here and things will adjust and get moving.
|
|
|
|
From linux Fri Feb 14 03:21:41 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <3214-0@banjo.concert.net>; Fri, 14 Feb 1992 03:21:00 -0500
|
|
Received: from ebs.eb.ele.tue.nl by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA02389; Fri, 14 Feb 92 03:20:53 -0500
|
|
Received: by ebs.eb.ele.tue.nl (5.65b/1.53) id AA06764;
|
|
Fri, 14 Feb 92 09:19:14 +0100
|
|
Date: Fri, 14 Feb 92 09:19:14 +0100
|
|
From: volf@eb.ele.tue.nl (Frank Volf)
|
|
Message-Id: <9202140819.AA06764@ebs.eb.ele.tue.nl>
|
|
To: dws@engr.uark.edu, linux-standards@concert.net
|
|
Subject: Re: Comments on Draft 2
|
|
|
|
|
|
You dws@engr.uark.edu (David W. Summers) wrote:
|
|
|
|
> I've been watching the debate about where to put Admin files and executables.
|
|
>
|
|
> What I would like is to have the executables either in /etc/bin or /usr/etc
|
|
> and the admin files themselves in /etc.
|
|
>
|
|
> Someone mentioned that they "didn't understand this fascination with keeping
|
|
> executables out of etc."
|
|
>
|
|
> Well, I would like to keep them out, because sometimes it is confusing
|
|
> (even to Sys. Admin. types like me! :-) whether or not a file (just by looking
|
|
> at the file name) is supposed to be an executable or a data file). I know,
|
|
> you can "ls -l" and see, but I like the separation of data files and executables
|
|
> like we normally have in other directories.
|
|
|
|
I partially agree with you, becuase novice (=non sysadmin) may be confused if they
|
|
examine /etc. But /etc is not for novice users!!!! It's for sys admin people
|
|
who know what they are doing (I hope). Sys admin's know which command they need
|
|
in a particular case. We (= the sys admins) do not examine /etc to look for
|
|
some interesting executable and then try it (like many novice users do with
|
|
/usr/games). We know which command we need and where the executable resides!
|
|
So from an theoretical point of view I agree, but in practice it ain't no problem.
|
|
|
|
>
|
|
> I agree there should probably not be any executables in /lib or /usr/lib, but
|
|
> then again, we need somewhere to put that stuff. I think that many (most?)
|
|
> times things like that should go in /etc/bin or /usr/etc.
|
|
>
|
|
> As to where root's home should go, how about "/root" ????
|
|
I agree root files should not go in /, just because it's a mess having around all
|
|
kind of dot (and possible other) files in /. I want to keep the / as clean as
|
|
possible (only the basic directories /bin /dev /etc .......) and possible some
|
|
interesting file like /vmlinux.
|
|
|
|
- David Summers
|
|
|
|
|
|
Best regards, Frank
|
|
|
|
------------------------------------------------------------------------
|
|
- Frank Volf INTERNET : volf@eb.ele.tue.nl -
|
|
- Eindhoven University of Technology -
|
|
- Digital Systems Group, Room EH10.16 -
|
|
- P.O. 513, -
|
|
- 5600 MB Eindhoven, The Netherlands -
|
|
------------------------------------------------------------------------
|
|
|
|
|
|
From linux Fri Feb 14 03:29:16 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <3263-0@banjo.concert.net>; Fri, 14 Feb 1992 03:28:39 -0500
|
|
Received: from daimi.aau.dk by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA02393; Fri, 14 Feb 92 03:28:35 -0500
|
|
Received: from ananke.daimi.aau.dk by daimi.aau.dk with SMTP (5.61++/IDA-1.2.8)
|
|
id AA28657; Fri, 14 Feb 92 09:27:07 +0100
|
|
Received: by ananke.daimi.aau.dk (5.64/1.34) id AA19946;
|
|
Fri, 14 Feb 92 09:27:03 +0100
|
|
Date: Fri, 14 Feb 92 09:27:03 +0100
|
|
From: tthorn@daimi.aau.dk
|
|
Message-Id: <9202140827.AA19946@ananke.daimi.aau.dk>
|
|
To: linux-standards@concert.net
|
|
Subject: Re: Comments on Draft 2, stop, stop, STOP..
|
|
|
|
This disscussion is getting out of hand and we are getting nowhere.
|
|
There will always be just one more remark and one more comment.
|
|
Taking the standard to vote is a *bad* idea, the hole point of
|
|
linux-standards is to make a forum for those who care to shape
|
|
*one* reference standard. Taking this to a vote will just delay
|
|
the standard (the ABC-release) to infinity.
|
|
|
|
I say: Lets accept draft 2, and get on to more interresting
|
|
problems. It might not be everybodys dream, but it's there.
|
|
As the situations is now, theres just anarchy.
|
|
|
|
Feel free not to flame.
|
|
/Tommy Thorn
|
|
|
|
From linux Fri Feb 14 22:36:39 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <8008-0@banjo.concert.net>; Fri, 14 Feb 1992 22:35:57 -0500
|
|
Received: from sun2.nsfnet-relay.ac.uk
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA14398;
|
|
Fri, 14 Feb 92 22:35:52 -0500
|
|
Message-Id: <9202150335.AA14398@jazz.concert.net>
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <25417-0@sun2.nsfnet-relay.ac.uk>; Fri, 14 Feb 1992 18:51:44 +0000
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa18668;
|
|
14 Feb 92 13:37 GMT
|
|
Date: Fri, 14 Feb 92 13:31:10 +0000
|
|
From: db1@ukc.ac.uk
|
|
To: linux-standards@concert.net
|
|
Subject: Root, partitions, directoryes
|
|
|
|
It seems to me that it is not clear why we need root to have
|
|
home in / and why something is needed in /bin /lib /etc
|
|
|
|
The point is to minimize the possible damage from a disk crash
|
|
and be able to do admin even with a half broken system.
|
|
|
|
Usually you put swap and root in one phisical disk and all the
|
|
rest of the partitions somewhere else. By doing this you
|
|
have less probability that a crash of ONE of your disks is going to
|
|
make your systm useless.
|
|
|
|
Infact if you have swap, root and all admin commands ( essential )
|
|
in one disk you can "repair" the damage fairly quickly.
|
|
|
|
The point is to select whta commands are "essential" ...... to do
|
|
repairing.
|
|
|
|
Something like
|
|
|
|
format
|
|
mkfs
|
|
init
|
|
login
|
|
getty
|
|
sh
|
|
vi
|
|
......
|
|
|
|
Anyway. I don't think root HAS to have .exrc .bashrc .mailrc ......
|
|
remembar the su is supposed to leave the environ intact
|
|
if you do not do su -
|
|
|
|
Damiano
|
|
|
|
|
|
From linux Fri Feb 14 22:50:56 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <8072-0@banjo.concert.net>; Fri, 14 Feb 1992 22:49:03 -0500
|
|
Received: from engr.uark.edu by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA14411; Fri, 14 Feb 92 22:49:00 -0500
|
|
Received: by engr.uark.edu (/\==/\ Smail3.1.25.1 #25.3)
|
|
id <m0lFGPr-00014LC@engr.uark.edu>; Fri, 14 Feb 92 21:50 CST
|
|
Message-Id: <m0lFGPr-00014LC@engr.uark.edu>
|
|
Date: Fri, 14 Feb 92 21:50 CST
|
|
From: dws@engr.uark.edu (David W. Summers)
|
|
To: db1@ukc.ac.uk
|
|
Subject: Re: Root, partitions, directoryes
|
|
Cc: linux-standards@concert.net
|
|
|
|
|
|
Maybe part of the problem people are having with directories in certain places
|
|
in the file system structure is that there has not been any talk (that I've
|
|
seen) about what partitions are assumed.
|
|
|
|
I know that on a SUN, there is the / (root) partition, a /usr partition which
|
|
is read-only, a /home partition for the users and a /var partition where
|
|
/var/tmp, /var/spool, etc. are place in.
|
|
|
|
Maybe this can help clear up why some people like directories in certain
|
|
places in the file system tree??????????
|
|
|
|
|
|
- David Summers
|
|
|
|
From linux Sat Feb 15 12:46:52 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <9403-0@banjo.concert.net>; Sat, 15 Feb 1992 12:46:12 -0500
|
|
Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA15347; Sat, 15 Feb 92 12:46:08 -0500
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA09787;
|
|
Sat, 15 Feb 92 12:45:53 -0500
|
|
Date: Sat, 15 Feb 92 12:45:53 -0500
|
|
From: tytso@ATHENA.MIT.edu (Theodore Ts'o)
|
|
Message-Id: <9202151745.AA09787@tsx-11.MIT.EDU>
|
|
To: dws@engr.uark.edu
|
|
Cc: db1@ukc.ac.uk, linux-standards@concert.net
|
|
In-Reply-To: David W. Summers's message of Fri, 14 Feb 92 21:50 CST, <m0lFGPr-00014LC@engr.uark.edu>
|
|
Subject: Re: Root, partitions, directoryes
|
|
Reply-To: tytso@athena.mit.edu
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
Date: Fri, 14 Feb 92 21:50 CST
|
|
From: dws@engr.uark.edu (David W. Summers)
|
|
|
|
I know that on a SUN, there is the / (root) partition, a /usr
|
|
partition which is read-only, a /home partition for the users and a
|
|
/var partition where /var/tmp, /var/spool, etc. are place in.
|
|
|
|
Hold on a second! Sun can assume that people need to have so many
|
|
partitions, because after all, Sun is a hardware manufacturer and makes
|
|
money selling disks. Some of us may not have the luxury of throwing so
|
|
many disks/partitions at the problem. That's why I've been plugging
|
|
/usr/home. People with one /usr partition can have /usr/home be in the
|
|
same partition as /usr, and people with more disks (and by extension,
|
|
money) to burn, can mount one of their copious numbers of partitions on
|
|
/usr/home.
|
|
|
|
In contrast, if you use /homes then you must either use a sym link from
|
|
/usr/homes to /homes, which gets confusing to users --- or you have to
|
|
use another partition. (Theoretically, I suppose you have a third
|
|
options of using one gigantic partition and mount it in /, but that's
|
|
not very satisfying either.)
|
|
|
|
I do agree, though, that we should just adopt the draft filesystem
|
|
standard, since I doubt we will be able to get accomplish much more by
|
|
merely flaming on the subject. To give it credit, it looks a lot less
|
|
like a camel(*) than many other standards efforts which I have seen, and it
|
|
is definitely better than what we have now.
|
|
|
|
- Ted
|
|
|
|
(*) Definition of a camel: a horse designed by committee
|
|
|
|
From linux Mon Feb 17 09:39:45 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Subject: Seen in comp.os.minix
|
|
To: linux-standards@concert.net
|
|
Date: Mon, 17 Feb 92 9:38:58 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@concert.net>
|
|
Sender: abc@concert.net
|
|
|
|
Just a bit of humor to lighten your day:
|
|
|
|
===
|
|
Snipped from someone's signature:
|
|
|
|
LINUXCY, n. Mental derangement caused by inability to appreciate another's
|
|
need for speed and pursuit of happiness, leading to excessive
|
|
flaming and waste of bandwidth !
|
|
===
|
|
|
|
BTW: Unless there are *STRONG* complaints, I am going to post "Draft 2" of
|
|
the Directory Standards Document to alt.os.linux, and linux-activists
|
|
on Wednesday, February 19.
|
|
|
|
I would like to release it as "Directory Standards Document 1.0" unless
|
|
there sre other ideas for a rational name.. (It will include the
|
|
header about it being completely voluntary, so we won't step on any
|
|
toes.)
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux Mon Feb 17 11:31:43 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <17912-0@banjo.concert.net>; Mon, 17 Feb 1992 11:30:09 -0500
|
|
Received: from sirius.brunel.ac.uk
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA05826;
|
|
Mon, 17 Feb 92 11:29:51 -0500
|
|
Received: from ccws-31.brunel.ac.uk by sirius.brunel.ac.uk with SMTP (PP)
|
|
id <01118-0@sirius.brunel.ac.uk>; Mon, 17 Feb 1992 16:27:57 +0000
|
|
From: Roger D Binns <cs89rdb@brunel.ac.uk>
|
|
Message-Id: <5351.9202171627@ccws-31.brunel.ac.uk>
|
|
Subject: Re: Seen in comp.os.minix
|
|
To: abc@concert.net (Alan B Clegg)
|
|
Date: Mon, 17 Feb 92 16:27:50 BST
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: <no.id>; from "Alan B Clegg" at Feb 17, 92 9:38 am
|
|
X-Mailer: ELM [version 2.2-hd PL 10]
|
|
|
|
> BTW: Unless there are *STRONG* complaints, I am going to post "Draft 2" of
|
|
> the Directory Standards Document to alt.os.linux, and linux-activists
|
|
> on Wednesday, February 19.
|
|
>
|
|
> I would like to release it as "Directory Standards Document 1.0" unless
|
|
> there sre other ideas for a rational name.. (It will include the
|
|
> header about it being completely voluntary, so we won't step on any
|
|
> toes.)
|
|
|
|
There are two things I think should be done first.
|
|
|
|
1) Mention this document in the install notes to give new people and
|
|
idea of what to do.
|
|
|
|
2) Make an mvdir available so that those of us who had to guess where
|
|
to put what when installing over the weekend can remedy the
|
|
situation ;-)
|
|
|
|
Roger
|
|
--
|
|
+=============================================================================+
|
|
| cs89rdb@brunel.ac.uk Roger Binns Brunel University - UK |
|
|
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
|
|
| Humans were created by water to move it uphill |
|
|
+=============================================================================+
|
|
|
|
From linux Mon Feb 17 12:54:05 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Subject: banjo.concert.net off-the-air
|
|
To: linux-standards@concert.net
|
|
Date: Mon, 17 Feb 92 12:52:39 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@concert.net>
|
|
Sender: abc@concert.net
|
|
|
|
Due to work (*yuck*) reasons, I have to upgrade banjo.concert.net from SunOS
|
|
4.1.1 to 4.1.2, and the easiest way to do that is to start over from scratch.
|
|
|
|
I will be doing this starting this afternoon (about 2:00pm EDT) and will be
|
|
done (hopefully by late tomorrow afternoon).
|
|
|
|
The Linux-Standards mailing list, as well as the anonymous FTP archives on
|
|
banjo will be out-of-service till I get everything going on this end. I will
|
|
continue to recieve mail sent to abc@concert.net, or abc@jazz.concert.net.
|
|
|
|
Sorry for the inconvenience, but work does come first...
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@concert.net Wed Feb 19 14:03:15 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from concert.net by banjo.concert.net id <11488-0@banjo.concert.net>;
|
|
Wed, 19 Feb 1992 14:03:00 -0500
|
|
Subject: List is back...
|
|
To: linux-standards@concert.net
|
|
Date: Wed, 19 Feb 92 14:02:56 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@concert.net>
|
|
Sender: abc@concert.net
|
|
|
|
The linux-standards mailing list is back in operation.
|
|
|
|
The FTP mirrors will be restarted this afternoon, depending on my disk space
|
|
crunch. Anyone have a couple of gig to donate? 8-)
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@concert.net Wed Feb 19 20:07:38 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <02175-0@banjo.concert.net>; Wed, 19 Feb 1992 20:07:26 -0500
|
|
Received: from relay1.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA09400; Wed, 19 Feb 92 20:07:24 -0500
|
|
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET
|
|
with SMTP (5.61/UUNET-internet-primary) id AA09852;
|
|
Wed, 19 Feb 92 20:07:17 -0500
|
|
Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail)
|
|
id 200639.16000; Wed, 19 Feb 1992 20:06:39 EST
|
|
Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA06241;
|
|
Wed, 19 Feb 92 16:54:29 PST
|
|
Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA04406;
|
|
Wed, 19 Feb 92 16:52:46 PST
|
|
Date: Wed, 19 Feb 92 16:52:46 PST
|
|
From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy)
|
|
Message-Id: <9202200052.AA04406@optisun17.optigfx.com>
|
|
To: linux-standards@concert.net
|
|
Subject: Re: Seen in comp.os.minix
|
|
|
|
In the also unforgettable words of Bruce Varney
|
|
>In the unforgettable words of Alan B Clegg:
|
|
>->
|
|
>->Just a bit of humor to lighten your day:
|
|
>->
|
|
>->BTW: Unless there are *STRONG* complaints, I am going to post "Draft 2" of
|
|
>-> the Directory Standards Document to alt.os.linux, and linux-activists
|
|
>-> on Wednesday, February 19.
|
|
|
|
>Admin binaries should be in /etc. That is my only complaint, and it
|
|
>is a *STRONG* one.
|
|
>->
|
|
Strongly agreed that admin binaries should be in /etc, including, but not
|
|
limited to /etc/init. I also have strong feelings about this. I seem to
|
|
remember a reference to /usr/uucp, too, rather than to /usr/lib/uucp. I
|
|
would prefer the /usr/lib/uucp /usr/spool/uucp pair, again, pretty strong
|
|
feelings...
|
|
|
|
The U**X rationale for the distribution of files between /etc, /bin, /usr/bin,
|
|
/lib, and /usr/lib weren't bad. I feel, however, that /usr/spool/cron and
|
|
/usr/lib/cron are misused in a "normal" U**X environment. It seems that
|
|
/usr/lib/cron should be used for the tables and definitions and such,
|
|
and that /usr/spool/cron should be used for the logs. Oh, well. Maybe the
|
|
tables and such would have been better in /etc/cron.d, analogous to /etc/rc.d,
|
|
/etc/rc0.d, and the like.
|
|
--
|
|
Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265
|
|
Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121
|
|
The opinion(s) expressed above are mine and not those of my employer.
|
|
|
|
From linux-standards-request@concert.net Wed Feb 19 23:11:07 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <03229-0@banjo.concert.net>; Wed, 19 Feb 1992 23:10:56 -0500
|
|
Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA10138; Wed, 19 Feb 92 23:10:54 -0500
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA15221;
|
|
Wed, 19 Feb 92 23:10:50 -0500
|
|
Date: Wed, 19 Feb 92 23:10:50 -0500
|
|
From: eichin@ATHENA.MIT.EDU ("Mark W. Eichin")
|
|
Message-Id: <9202200410.AA15221@tsx-11.MIT.EDU>
|
|
To: optigfx!optisun17!mrm@uunet.UU.NET
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: Mike Murphy's message of Wed, 19 Feb 92 16:52:46 PST <9202200052.AA04406@optisun17.optigfx.com>
|
|
Subject: re: Seen in comp.os.minix
|
|
|
|
A few people are...
|
|
>>> Strongly agreed that admin binaries should be in /etc, including, but not
|
|
Sorry... either have binaries there, or config files -- *Not*
|
|
both. The BSD 4.4 model (which I think is what one of the draft posix
|
|
standards is related to, if not derived from) has config files in /etc
|
|
and executables in /usr/etc/ (DEC Ultrix and SunOS have already
|
|
adopted this.) Having executables in /etc may be "traditional", but
|
|
that's just because it is a traditional mistake...
|
|
_Mark_ <eichin@athena.mit.edu>
|
|
MIT Student Information Processing Board
|
|
|
|
|
|
From linux-standards-request@concert.net Thu Feb 20 02:53:38 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <03812-0@banjo.concert.net>; Thu, 20 Feb 1992 02:53:28 -0500
|
|
Received: from sun2.nsfnet-relay.ac.uk
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA10568;
|
|
Thu, 20 Feb 92 02:53:21 -0500
|
|
Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk
|
|
via JANET with NIFTP id <1262-0@sun2.nsfnet-relay.ac.uk>;
|
|
Thu, 20 Feb 1992 07:19:16 +0000
|
|
Message-Id: <20 Feb 92 07:14:37 GMT ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Thu, 20 Feb 92 07:14:37 GMT
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
Myname: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@concert.net>
|
|
Subject: location of logs
|
|
|
|
|
|
I note with concern a reference to various logs going in
|
|
/usr/spool.
|
|
|
|
The task of making Linux better requires a balance between
|
|
avoiding too much peculiarity (making Linux more 'standard')
|
|
and pursuing simplicity (helping idiots set up and use Linux).
|
|
|
|
One of the most irritating tasks I have as a sysadmin is cleaning
|
|
out thousands of log files. On my systems there are logs in
|
|
/etc, in /usr/adm, in /usr/etc, in /usr/spool, and in literally
|
|
thousands of user directories (x/motif session error logs).
|
|
Preventing this rubbish from piling up is a major nuisance.
|
|
One advantage of having /var is to get all the stuff in one place.
|
|
Another is to put all the growing files on one partition, where it
|
|
can cause less havoc in the file system when it gets full. This
|
|
makes administering the system simpler. If conformity is threatened,
|
|
we can always make /etc/wtmp, /usr/adm/syslog, /usr/spool/lp/log,
|
|
etc, be symbolic links to files in /var. That way security can be
|
|
checked, and then all logs deleted, e.g., by
|
|
|
|
find /var -type f -exec rm {} \;
|
|
|
|
which could be put in a script for the non-Unix literate.
|
|
|
|
A. V. Le Blanc
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux-standards-request@concert.net Thu Feb 20 03:20:21 1992
|
|
Return-Path: <linux-standards-request@concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <03917-0@banjo.concert.net>; Thu, 20 Feb 1992 03:20:09 -0500
|
|
Received: from sun2.nsfnet-relay.ac.uk
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA10638;
|
|
Thu, 20 Feb 92 03:20:06 -0500
|
|
Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk
|
|
via JANET with NIFTP id <2437-0@sun2.nsfnet-relay.ac.uk>;
|
|
Thu, 20 Feb 1992 08:11:57 +0000
|
|
Message-Id: <20 Feb 92 07:32:41 GMT ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Thu, 20 Feb 92 07:32:41 GMT
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
Myname: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@concert.net>
|
|
Subject: admin binaries and configuration
|
|
|
|
|
|
Two points:
|
|
|
|
1) To decide that something is a binary for administrative
|
|
purposes only is harder on Linux than it is on most systems.
|
|
For example, you should be able to format, mkfs, and mount
|
|
a floppy disk without being root. For this reason, format,
|
|
mkfs, mount, umount, fsck, etc., may well need to be in /bin
|
|
instead of in /etc, where most Unixes would put them. On
|
|
the other hand, I think init and update should probably not
|
|
be in /bin, since even root ought not normally execute them
|
|
as commands. This is why I suggested in an earlier note that
|
|
they ought to go in /lib. Someone objected that /lib ought
|
|
not contain executables. What about /lib/cpp, /usr/lib/sendmail,
|
|
and such executables, which are traditionally in library
|
|
directories? Personally I suspect cpp belongs in a bin
|
|
somewhere. What about daemons?
|
|
|
|
2) I suggest that files be distinguished into
|
|
|
|
a) Configuration files (passwd, group, inetd.conf).
|
|
b) Executables and scripts which only root should run,
|
|
even on Linux (telinit, shutdown, reboot).
|
|
c) Executables which not even root should normally run
|
|
(update, gated, inetd).
|
|
|
|
Now, when I think in these terms, I find it awfully difficult
|
|
to be clear about these categories. What about rc, for
|
|
example; does it belong in a, in b, or in c? If we have a
|
|
special directory for root-only executables, shouldn't all,
|
|
or almost all, of (c) be in it as well as (b), since under
|
|
some circumstances root may want to start these off manually?
|
|
|
|
In short, while I sympathise most strongly with those who
|
|
would like to see the stuff in /etc be homogeneous, I am not
|
|
at all certain that it can be done. At best we might put
|
|
configuration files in /etc and the rest in /etc/bin, or
|
|
binaries in /etc and the rest in /etc/conf.
|
|
|
|
A. V. Le Blanc
|
|
University of Manchester
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 20 10:48:24 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <07877-0@banjo.concert.net>; Thu, 20 Feb 1992 10:47:57 -0500
|
|
Received: from engr.uark.edu by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA14932; Thu, 20 Feb 92 10:47:54 -0500
|
|
Received: by engr.uark.edu (/\==/\ Smail3.1.25.1 #25.3)
|
|
id <m0lHG1H-00014JC@engr.uark.edu>; Thu, 20 Feb 92 09:49 CST
|
|
Message-Id: <m0lHG1H-00014JC@engr.uark.edu>
|
|
Date: Thu, 20 Feb 92 09:49 CST
|
|
From: dws@engr.uark.edu (David W. Summers)
|
|
To: linux-standards@concert.net
|
|
Subject: re: Seen in comp.os.minix
|
|
|
|
|
|
----- Begin Included Message -----
|
|
|
|
>From concert.net!linux-standards-request Wed Feb 19 22:14:24 1992
|
|
Date: Wed, 19 Feb 92 23:10:50 -0500
|
|
From: eichin@ATHENA.MIT.EDU ("Mark W. Eichin")
|
|
To: optigfx!optisun17!mrm@uunet.UU.NET
|
|
Cc: linux-standards@concert.net
|
|
Subject: re: Seen in comp.os.minix
|
|
Content-Length: 566
|
|
|
|
A few people are...
|
|
>>> Strongly agreed that admin binaries should be in /etc, including, but not
|
|
Sorry... either have binaries there, or config files -- *Not*
|
|
both. The BSD 4.4 model (which I think is what one of the draft posix
|
|
standards is related to, if not derived from) has config files in /etc
|
|
and executables in /usr/etc/ (DEC Ultrix and SunOS have already
|
|
adopted this.) Having executables in /etc may be "traditional", but
|
|
that's just because it is a traditional mistake...
|
|
_Mark_ <eichin@athena.mit.edu>
|
|
MIT Student Information Processing Board
|
|
|
|
|
|
|
|
----- End Included Message -----
|
|
|
|
Hooray for our side! :-)
|
|
|
|
This is what I was trying to get across in my previous posting.
|
|
|
|
I hadn't realized that several people have STRONG feelings against this!
|
|
|
|
I completely agree with having just admin. files in /etc and executables in
|
|
/usr/etc.
|
|
|
|
- David Summers
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 20 10:53:30 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <08063-0@banjo.concert.net>; Thu, 20 Feb 1992 10:52:55 -0500
|
|
Received: from engr.uark.edu by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA14993; Thu, 20 Feb 92 10:52:48 -0500
|
|
Received: by engr.uark.edu (/\==/\ Smail3.1.25.1 #25.3)
|
|
id <m0lHG61-00014JC@engr.uark.edu>; Thu, 20 Feb 92 09:54 CST
|
|
Message-Id: <m0lHG61-00014JC@engr.uark.edu>
|
|
Date: Thu, 20 Feb 92 09:54 CST
|
|
From: dws@engr.uark.edu (David W. Summers)
|
|
To: linux-standards@concert.net
|
|
Subject: location of logs
|
|
|
|
|
|
----- Begin Included Message -----
|
|
|
|
>From concert.net!linux-standards-request Thu Feb 20 02:02:27 1992
|
|
Date: Thu, 20 Feb 92 07:14:37 GMT
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
Myname: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@concert.net>
|
|
Subject: location of logs
|
|
Content-Length: 1161
|
|
|
|
|
|
I note with concern a reference to various logs going in
|
|
/usr/spool.
|
|
|
|
The task of making Linux better requires a balance between
|
|
avoiding too much peculiarity (making Linux more 'standard')
|
|
and pursuing simplicity (helping idiots set up and use Linux).
|
|
|
|
One of the most irritating tasks I have as a sysadmin is cleaning
|
|
out thousands of log files. On my systems there are logs in
|
|
/etc, in /usr/adm, in /usr/etc, in /usr/spool, and in literally
|
|
thousands of user directories (x/motif session error logs).
|
|
Preventing this rubbish from piling up is a major nuisance.
|
|
One advantage of having /var is to get all the stuff in one place.
|
|
Another is to put all the growing files on one partition, where it
|
|
can cause less havoc in the file system when it gets full. This
|
|
makes administering the system simpler. If conformity is threatened,
|
|
we can always make /etc/wtmp, /usr/adm/syslog, /usr/spool/lp/log,
|
|
etc, be symbolic links to files in /var. That way security can be
|
|
checked, and then all logs deleted, e.g., by
|
|
|
|
find /var -type f -exec rm {} \;
|
|
|
|
which could be put in a script for the non-Unix literate.
|
|
|
|
A. V. Le Blanc
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
|
|
----- End Included Message -----
|
|
|
|
YES YES YES!
|
|
|
|
Notice /var/log directory in SunOS. /var is (usually) a separate partition
|
|
in SunOS and the Sys. Admin. chooses how big he will make it.
|
|
|
|
This makes it VERY NICE from a Sys. Admin. point of view. If I DON'T have
|
|
room for a /var partition, then I usually make it a sym-link to somewhere
|
|
that has extra space left over for misc. stuff.
|
|
|
|
- David Summers
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 20 11:06:12 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <08838-0@banjo.concert.net>; Thu, 20 Feb 1992 11:05:49 -0500
|
|
Received: from daimi.aau.dk by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA15116; Thu, 20 Feb 92 11:05:46 -0500
|
|
Received: from bentley.daimi.aau.dk by daimi.aau.dk
|
|
with SMTP (5.61++/IDA-1.2.8) id AA06578;
|
|
Thu, 20 Feb 92 17:05:38 +0100
|
|
Received: by bentley.daimi.aau.dk (5.64/1.34) id AA24073;
|
|
Thu, 20 Feb 92 17:05:33 +0100
|
|
Date: Thu, 20 Feb 92 17:05:33 +0100
|
|
From: tthorn@daimi.aau.dk
|
|
Message-Id: <9202201605.AA24073@bentley.daimi.aau.dk>
|
|
To: linux-standards@concert.net
|
|
In-Reply-To: David W. Summers's message of Thu, 20 Feb 92 09:49 CST <m0lHG1H-00014JC@engr.uark.edu>
|
|
Subject: /etc and /usr/etc [was re: Seen in comp.os.minix]
|
|
|
|
> From: dws@engr.uark.edu (David W. Summers)
|
|
>
|
|
> I completely agree with having just admin. files in /etc and executables
|
|
> in /usr/etc.
|
|
|
|
Bzzzz. Wrong guess Hans:-) The consequence of this would be that things like
|
|
init would be in /usr/etc, which might not even be mounted at the time
|
|
init should be run.
|
|
|
|
In retrospect I also think that /bin/init is a bad idea, but then it should
|
|
be /lib/init.
|
|
|
|
...../lib should contrain libraries, support files *and* executables which
|
|
shouldn't be in anyones path.
|
|
|
|
And with this small change I'd like to see the Draft accepted.
|
|
|
|
/Tommy Thorn
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 20 11:43:14 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <11701-0@banjo.concert.net>; Thu, 20 Feb 1992 11:41:33 -0500
|
|
Received: from banjo.concert.net by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA15510; Thu, 20 Feb 92 11:41:11 -0500
|
|
Message-Id: <9202201641.AA15510@jazz.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <07999-0@banjo.concert.net>; Thu, 20 Feb 1992 10:51:39 -0500
|
|
Subject: re: Seen in comp.os.minix
|
|
To: dws@engr.uark.edu (David W. Summers)
|
|
Date: Thu, 20 Feb 92 10:51:35 EST
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: <m0lHG1H-00014JC@engr.uark.edu>; from "David W. Summers" at Feb 20, 92 9:49 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
> I completely agree with having just admin. files in /etc and executables in
|
|
> /usr/etc.
|
|
|
|
Ok, put init in /usr/etc, and make sure /usr is mounted just before you
|
|
exec it.
|
|
|
|
Minor problem.
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 20 11:43:15 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <11702-0@banjo.concert.net>; Thu, 20 Feb 1992 11:41:33 -0500
|
|
Received: from banjo.concert.net by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA15522; Thu, 20 Feb 92 11:41:16 -0500
|
|
Message-Id: <9202201641.AA15522@jazz.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <08868-0@banjo.concert.net>; Thu, 20 Feb 1992 11:07:59 -0500
|
|
Subject: Re: location of logs
|
|
To: dws@engr.uark.edu (David W. Summers)
|
|
Date: Thu, 20 Feb 92 11:07:55 EST
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: <m0lHG61-00014JC@engr.uark.edu>; from "David W. Summers" at Feb 20, 92 9:54 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
> From: LeBlanc@manchester-computing-centre.ac.uk
|
|
|
|
[ Discussion of /var ]
|
|
|
|
> find /var -type f -exec rm {} \;
|
|
|
|
You are kidding, right? /var/spool/mail ... *POOF* /var/spool/news *POOF*
|
|
|
|
*NOT A GOOD IDEA*
|
|
|
|
> which could be put in a script for the non-Unix literate.
|
|
|
|
Linux is not for 'the non-Unix literate'.
|
|
|
|
To which David W. Summers replies:
|
|
|
|
> Notice /var/log directory in SunOS. /var is (usually) a separate partition
|
|
> in SunOS and the Sys. Admin. chooses how big he will make it.
|
|
|
|
The sysadm chooses how large *EVERY* partition is. What matter is it that
|
|
it is hanging off of /usr or /var?
|
|
|
|
> This makes it VERY NICE from a Sys. Admin. point of view. If I DON'T have
|
|
> room for a /var partition, then I usually make it a sym-link to somewhere
|
|
> that has extra space left over for misc. stuff.
|
|
|
|
So what is the difference here of mounting something on top of /usr/adm, or
|
|
making *IT* a symlink?
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 20 11:43:31 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <11706-0@banjo.concert.net>; Thu, 20 Feb 1992 11:41:33 -0500
|
|
Received: from banjo.concert.net by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA15529; Thu, 20 Feb 92 11:41:21 -0500
|
|
Message-Id: <9202201641.AA15529@jazz.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <08926-0@banjo.concert.net>; Thu, 20 Feb 1992 11:15:33 -0500
|
|
Subject: Re: /etc and /usr/etc [was re: Seen in comp.os.minix]
|
|
To: tthorn@daimi.aau.dk
|
|
Date: Thu, 20 Feb 92 11:15:29 EST
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: <9202201605.AA24073@bentley.daimi.aau.dk>; from "tthorn@daimi.aau.dk" at Feb 20, 92 5:05 pm
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
> In retrospect I also think that /bin/init is a bad idea, but then it should
|
|
> be /lib/init.
|
|
|
|
Agreed.
|
|
|
|
> ...../lib should contrain libraries, support files *and* executables which
|
|
> shouldn't be in anyones path.
|
|
>
|
|
> And with this small change I'd like to see the Draft accepted.
|
|
|
|
Agreed. I will make the change. All in favor? All opposed? Good.
|
|
It passes. (seriously, one last day to bring up comments).
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 20 12:41:25 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <12131-0@banjo.concert.net>; Thu, 20 Feb 1992 12:41:12 -0500
|
|
Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA16308; Thu, 20 Feb 92 12:41:06 -0500
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA16696;
|
|
Thu, 20 Feb 92 12:40:14 -0500
|
|
Date: Thu, 20 Feb 92 12:40:14 -0500
|
|
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
|
|
Message-Id: <9202201740.AA16696@tsx-11.MIT.EDU>
|
|
To: dws@engr.uark.edu
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: David W. Summers's message of Thu, 20 Feb 92 09:49 CST, <m0lHG1H-00014JC@engr.uark.edu>
|
|
Subject: Re: Seen in comp.os.minix
|
|
Reply-To: tytso@athena.mit.edu
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
Sorry... either have binaries there, or config files -- *Not*
|
|
both. The BSD 4.4 model (which I think is what one of the draft posix
|
|
standards is related to, if not derived from) has config files in /etc
|
|
and executables in /usr/etc/ (DEC Ultrix and SunOS have already
|
|
adopted this.) Having executables in /etc may be "traditional", but
|
|
that's just because it is a traditional mistake...
|
|
|
|
No, that's not the BSD 4.4 model; they have /sbin for the admin
|
|
binaries. The problem is that you need to start /usr/etc/init before
|
|
/usr is mounted....
|
|
|
|
Look, this seems to be going nowhere. We can't just blindly point and
|
|
say look! BSD 4.3 did it this way! Sun OS did it that way! The only
|
|
reason why we were doing this was that we don't want to screw users
|
|
who have always been used to finding programs in particular places
|
|
(/etc/mount, /bin/grep, /bin/ed, etc., etc.). But aside from that, we
|
|
need to architect something that works as a cohesive whole.
|
|
|
|
Putting init in /usr/etc when it was previously assumed that /usr might
|
|
be a mounted partition, all in the name of "Horray for our side!" is
|
|
going to result in a camel --- a horse designed by a committee. Before
|
|
we get all wrapped up in aesthetics, let's come up with a cohesive
|
|
document THAT WORKS.
|
|
|
|
Slightly annoyed,
|
|
|
|
- Ted
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 20 23:26:29 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <21295-0@banjo.concert.net>; Thu, 20 Feb 1992 16:05:35 -0500
|
|
Received: from relay1.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA21429; Thu, 20 Feb 92 16:05:31 -0500
|
|
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET
|
|
with SMTP (5.61/UUNET-internet-primary) id AA14190;
|
|
Thu, 20 Feb 92 16:05:21 -0500
|
|
Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail)
|
|
id 160427.9260; Thu, 20 Feb 1992 16:04:27 EST
|
|
Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA18092;
|
|
Thu, 20 Feb 92 12:38:24 PST
|
|
Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA04793;
|
|
Thu, 20 Feb 92 12:36:41 PST
|
|
Date: Thu, 20 Feb 92 12:36:41 PST
|
|
From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy)
|
|
Message-Id: <9202202036.AA04793@optisun17.optigfx.com>
|
|
To: uunet!ATHENA.MIT.EDU!eichin@uunet.UU.NET
|
|
Subject: re: Seen in comp.os.minix
|
|
Cc: linux-standards@concert.net
|
|
|
|
_Mark_ <eichin@athena.mit.edu> writes:
|
|
|
|
>A few people are...
|
|
still :-)
|
|
>>>> Strongly agreed that admin binaries should be in /etc, including, but not
|
|
> Sorry... either have binaries there, or config files -- *Not*
|
|
>both. The BSD 4.4 model (which I think is what one of the draft posix
|
|
>standards is related to, if not derived from) has config files in /etc
|
|
>and executables in /usr/etc/ (DEC Ultrix and SunOS have already
|
|
>adopted this.) Having executables in /etc may be "traditional", but
|
|
>that's just because it is a traditional mistake...
|
|
|
|
Not a mistake :-) It follows the KISS principle, which, I would suggest, has been
|
|
sorely ignored in "modern" U**X. Again, oh, well.
|
|
|
|
I kind of like the root path "/bin:/etc:/usr/bin". The implication is that the
|
|
executables required for system maintenance/startup are in /etc (maybe symlinks,
|
|
who cares except for KISS), and that they are not, nor do they need to be, in the
|
|
"normal" user path. I'd also like to see the permissions for something like
|
|
/etc/fsck be 0110, owned by root and group sys or system or the like.
|
|
|
|
Sticking executables in /usr/etc may be or may not be a "good thing" otherwise, but
|
|
it can really make backup/restore cycles a pain. It also can make life a royal pain
|
|
if in single user mode the /usr filesystem(s) aren't mounted. It is shortsighted to
|
|
be a purist WRT splitting of configuration and executable, I think.
|
|
|
|
I would propose a far simpler directory structure:
|
|
|
|
/ root, to contain as little as possible, just what's required for
|
|
single user mode
|
|
|
|
At the next lowest level:
|
|
/bin/ commonly used binaries, necessary for single user nothing else but
|
|
the root device mounted
|
|
/dev/ device special files
|
|
/etc/ system configuration, startup, maintenance
|
|
/export/ mount point for directories/filesystems to be exported over a network
|
|
/home/ mount point for directories of groups of users homed on the system
|
|
/lib/ libraries required for system operation, e.g., shared libraries, just what's
|
|
required for single user mode
|
|
/lost+found/ disaster recovery :-)
|
|
/usr/ mount point for system components required for more than single user
|
|
maintenance functions, such as /usr/adm/, /usr/bin/, /usr/lib/, and
|
|
/usr/spool
|
|
/vmlinux :-)
|
|
|
|
Note that I specifically leave out /mnt
|
|
|
|
And then, heirarchically, stuff like:
|
|
/dev/dsk/ disks
|
|
/dev/lp/ printers
|
|
/dev/net/ networks
|
|
/dev/tty/ locally connected serial ports
|
|
..
|
|
/etc/conf.d/ configuration
|
|
..
|
|
/etc/rc0.d/ single user rc
|
|
/etc/rc2.d/ multi-user rc (and so on...)
|
|
..
|
|
|
|
Setting up a system that won't run single user with nothing mounted is probably a pretty
|
|
bad idea. Setting up a system that can't be expanded to cope with 4 SCSI controllers with
|
|
2 tapes, 10 disk drives, 6 printers, and a coffee pot interface is also probably a shame
|
|
if it can be easily avoided.
|
|
--
|
|
Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265
|
|
Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121
|
|
The opinion(s) expressed above are mine and not those of my employer.
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 20 23:26:30 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <22204-0@banjo.concert.net>; Thu, 20 Feb 1992 16:07:58 -0500
|
|
Received: from relay1.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA21533; Thu, 20 Feb 92 16:07:50 -0500
|
|
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET
|
|
with SMTP (5.61/UUNET-internet-primary) id AA14168;
|
|
Thu, 20 Feb 92 16:05:18 -0500
|
|
Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail)
|
|
id 160429.9288; Thu, 20 Feb 1992 16:04:29 EST
|
|
Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA18540;
|
|
Thu, 20 Feb 92 12:52:28 PST
|
|
Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA04853;
|
|
Thu, 20 Feb 92 12:50:45 PST
|
|
Date: Thu, 20 Feb 92 12:50:45 PST
|
|
From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy)
|
|
Message-Id: <9202202050.AA04853@optisun17.optigfx.com>
|
|
To: uunet!manchester-computing-centre.ac.uk!LeBlanc@uunet.UU.NET
|
|
Subject: Re: admin binaries and configuration
|
|
Cc: linux-standards@concert.net
|
|
|
|
A. V. Le Blanc writes:
|
|
|
|
>Two points:
|
|
>
|
|
>1) To decide that something is a binary for administrative
|
|
> purposes only is harder on Linux than it is on most systems.
|
|
> For example, you should be able to format, mkfs, and mount
|
|
> a floppy disk without being root. For this reason, format,
|
|
> mkfs, mount, umount, fsck, etc., may well need to be in /bin
|
|
> instead of in /etc, where most Unixes would put them. On
|
|
> the other hand, I think init and update should probably not
|
|
> be in /bin, since even root ought not normally execute them
|
|
> as commands. This is why I suggested in an earlier note that
|
|
> they ought to go in /lib. Someone objected that /lib ought
|
|
> not contain executables. What about /lib/cpp, /usr/lib/sendmail,
|
|
> and such executables, which are traditionally in library
|
|
> directories? Personally I suspect cpp belongs in a bin
|
|
> somewhere. What about daemons?
|
|
|
|
The security problems mounting a floppy disk are interesting :-)
|
|
It may well be desirable to limit access to such functions as format,
|
|
fsck, mkfs, mount, et.al. in order to maintain a stable computing
|
|
environment. I am suggesting here that linux and what it becomes
|
|
could be in a large multi-user environment, a process control
|
|
environment, a who-knows-how-used envrionment. If it's a system
|
|
maintenance function, e.g., fsck, then I think it ought to live
|
|
in /etc. Just opinion, but my use of a system may not match someone
|
|
elses.
|
|
|
|
>
|
|
>2) I suggest that files be distinguished into
|
|
>
|
|
> a) Configuration files (passwd, group, inetd.conf).
|
|
> b) Executables and scripts which only root should run,
|
|
> even on Linux (telinit, shutdown, reboot).
|
|
> c) Executables which not even root should normally run
|
|
> (update, gated, inetd).
|
|
>
|
|
> Now, when I think in these terms, I find it awfully difficult
|
|
> to be clear about these categories. What about rc, for
|
|
> example; does it belong in a, in b, or in c? If we have a
|
|
> special directory for root-only executables, shouldn't all,
|
|
> or almost all, of (c) be in it as well as (b), since under
|
|
> some circumstances root may want to start these off manually?
|
|
>
|
|
> In short, while I sympathise most strongly with those who
|
|
> would like to see the stuff in /etc be homogeneous, I am not
|
|
> at all certain that it can be done. At best we might put
|
|
> configuration files in /etc and the rest in /etc/bin, or
|
|
> binaries in /etc and the rest in /etc/conf.
|
|
|
|
Sounds pretty good, except for the dire consequences of having format
|
|
live in /bin :-)
|
|
--
|
|
Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265
|
|
Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121
|
|
The opinion(s) expressed above are mine and not those of my employer.
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 20 23:26:31 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <22208-0@banjo.concert.net>; Thu, 20 Feb 1992 16:07:58 -0500
|
|
Received: from relay2.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA21535; Thu, 20 Feb 92 16:07:51 -0500
|
|
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET
|
|
with SMTP (5.61/UUNET-internet-primary) id AA25603;
|
|
Thu, 20 Feb 92 16:05:25 -0500
|
|
Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail)
|
|
id 160428.9273; Thu, 20 Feb 1992 16:04:28 EST
|
|
Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA18216;
|
|
Thu, 20 Feb 92 12:45:44 PST
|
|
Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA04845;
|
|
Thu, 20 Feb 92 12:44:02 PST
|
|
Date: Thu, 20 Feb 92 12:44:02 PST
|
|
From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy)
|
|
Message-Id: <9202202044.AA04845@optisun17.optigfx.com>
|
|
To: uunet!manchester-computing-centre.ac.uk!LeBlanc@uunet.UU.NET
|
|
Subject: Re: location of logs
|
|
Cc: linux-standards@concert.net
|
|
|
|
A. V. Le Blanc writes:
|
|
|
|
>I note with concern a reference to various logs going in
|
|
>/usr/spool.
|
|
|
|
The nit I was picking was the the log files that end up
|
|
in /usr/lib, which I think should be a pretty static kind
|
|
of place. Better to have the log files for cron show up in
|
|
/usr/spool/cron rather than in /usr/lib/cron. Also better
|
|
to have the configuration for cron in /usr/lib/cron rather
|
|
than in /usr/spool/cron. That was my point. WRT to logfiles
|
|
being strewn throughout a directory heirarchy, I agree that
|
|
it's a pain to administer. Log trimming is a chore no matter
|
|
how it's to be done. Symbolic links could make things easier.
|
|
The above is opinion to be taken with more than one grain
|
|
of salt...
|
|
--
|
|
Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265
|
|
Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121
|
|
The opinion(s) expressed above are mine and not those of my employer.
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Feb 21 08:43:10 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <01623-0@banjo.concert.net>; Fri, 21 Feb 1992 08:41:41 -0500
|
|
Received: from ux.acs.umn.edu by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA23802; Fri, 21 Feb 92 01:32:56 -0500
|
|
Received: by ux.acs.umn.edu (5.65c/) id AA17605; Fri, 21 Feb 1992 00:33:55 -0600
|
|
From: "Mr. Big Stuff" <brian@ux.acs.umn.edu>
|
|
Message-Id: <199202210633.AA17605@ux.acs.umn.edu>
|
|
Subject: Re: location of logs
|
|
To: linux-standards@concert.net
|
|
Date: Fri, 21 Feb 92 0:33:49 CST
|
|
In-Reply-To: <m0lHG61-00014JC@engr.uark.edu>; from "David W. Summers" at Feb 20, 92 9:54 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
David W. Summers must have playing with Crayolas when s/he/it/them wrote:
|
|
>LeBlanc@manchester-computing-centre.ac.uk writes:
|
|
>>One of the most irritating tasks I have as a sysadmin is cleaning
|
|
>>out thousands of log files. On my systems there are logs in
|
|
...
|
|
>>One advantage of having /var is to get all the stuff in one place.
|
|
>>Another is to put all the growing files on one partition, where it
|
|
>>can cause less havoc in the file system when it gets full. This
|
|
>>makes administering the system simpler. If conformity is threatened,
|
|
|
|
>YES YES YES!
|
|
>Notice /var/log directory in SunOS. /var is (usually) a separate partition
|
|
>in SunOS and the Sys. Admin. chooses how big he will make it.
|
|
|
|
In spite of my standard reply header, I agree with all of the above.
|
|
Putting all the logs in one place would make a *big* difference in the ease
|
|
of maintaining linux. And making sure that (say) a 30+Meg logfile doesn't
|
|
bring your system to it's knees is a good thing. Not that I've seen that :-)
|
|
|
|
Since there is already a 'standard' place to put log files (/var/log) I
|
|
won't even think of suggesting /log :-)
|
|
|
|
The proposed standard file system should be changed to reflect a log
|
|
directory, IMHO.
|
|
|
|
--
|
|
Brian
|
|
brian@ux.acs.umn.edu
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Feb 21 08:43:33 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <01678-0@banjo.concert.net>; Fri, 21 Feb 1992 08:42:22 -0500
|
|
Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA23543; Fri, 21 Feb 92 00:04:45 -0500
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA18977;
|
|
Fri, 21 Feb 92 00:04:40 -0500
|
|
Date: Fri, 21 Feb 92 00:04:40 -0500
|
|
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
|
|
Message-Id: <9202210504.AA18977@tsx-11.MIT.EDU>
|
|
To: optigfx!optisun17!mrm@uunet.UU.NET
|
|
Cc: linux-standards@concert.net
|
|
In-Reply-To: Mike Murphy's message of Thu, 20 Feb 92 12:36:41 PST, <9202202036.AA04793@optisun17.optigfx.com>
|
|
Subject: Re: Seen in comp.os.minix
|
|
Reply-To: tytso@athena.mit.edu
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
Date: Thu, 20 Feb 92 12:36:41 PST
|
|
From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy)
|
|
|
|
Not a mistake :-) It follows the KISS principle, which, I would
|
|
suggest, has been sorely ignored in "modern" U**X. Again, oh, well.....
|
|
|
|
[....]
|
|
|
|
I would propose a far simpler directory structure:
|
|
|
|
And then, heirarchically, stuff like:
|
|
/dev/dsk/ disks
|
|
/dev/lp/ printers
|
|
/dev/net/ networks
|
|
/dev/tty/ locally connected serial ports
|
|
..
|
|
/etc/conf.d/ configuration
|
|
..
|
|
/etc/rc0.d/ single user rc
|
|
/etc/rc2.d/ multi-user rc (and so on...)
|
|
..
|
|
|
|
Somehow, I have trouble reconciling your first statement about KISS with
|
|
your proposal where you have hierarchies under /dev. I suspect this
|
|
will break more than a few programs, as well as people's mindsets. (It
|
|
would certainly break my stock login scripts, which play funky games
|
|
with `ttyname`.)
|
|
|
|
I am correct in assuming that the current draft proposal does *NOT*
|
|
suggest use of such a hierarchy in /dev, right? If so, I hope we keep
|
|
it that way....
|
|
|
|
- Ted
|
|
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Feb 21 08:49:30 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <01560-0@banjo.concert.net>; Fri, 21 Feb 1992 08:40:59 -0500
|
|
Received: from golem.wcc.govt.nz by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA23877; Fri, 21 Feb 92 02:42:54 -0500
|
|
Received: from csc.wcc.govt.nz by golem.wcc.govt.nz id <AA06436-5.65a+VUW/4.0>;
|
|
Fri, 21 Feb 92 20:43:45 +1300
|
|
Received: by csc.wcc.govt.nz (MX V3.0) id 1111; Fri, 21 Feb 1992 20:45:08 EST
|
|
Sender: hamilton <hamilton@csc.wcc.govt.nz>
|
|
Date: Fri, 21 Feb 1992 20:45:02 EST
|
|
From: hamilton@csc.wcc.govt.nz
|
|
To: linux-standards@concert.net
|
|
Cc: hamilton@csc.wcc.govt.nz
|
|
Message-Id: <00956816.E2430520.1111@csc.wcc.govt.nz>
|
|
Subject: Seen in comp.os.minix
|
|
|
|
|
|
I know it's not standard, but how about /etc/bin and /etc/log, and/or
|
|
/usr/etc/bin and /usr/etc/log as appropriate. Or if we want to keep
|
|
things "standard", I would vote with KISS, i.e. "/bin:/etc:/usr/bin",
|
|
with no links, symbolic or otherwise.
|
|
|
|
I very much dislike the idea of having to have /usr/etc around to get
|
|
at admin binaries.
|
|
|
|
As for cleaning up log files, I would suggest a standard clean_logs
|
|
shell script (or some similar scheme).
|
|
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Feb 21 12:36:02 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <15234-0@banjo.concert.net>; Fri, 21 Feb 1992 12:35:23 -0500
|
|
Received: from relay1.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA01425; Fri, 21 Feb 92 12:35:18 -0500
|
|
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET
|
|
with SMTP (5.61/UUNET-internet-primary) id AA06182;
|
|
Fri, 21 Feb 92 12:35:06 -0500
|
|
Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail)
|
|
id 123434.9470; Fri, 21 Feb 1992 12:34:34 EST
|
|
Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA18954;
|
|
Thu, 20 Feb 92 13:26:08 PST
|
|
Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA04998;
|
|
Thu, 20 Feb 92 13:24:26 PST
|
|
Date: Thu, 20 Feb 92 13:24:26 PST
|
|
From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy)
|
|
Message-Id: <9202202124.AA04998@optisun17.optigfx.com>
|
|
To: uunet!banjo.concert.net!abc@uunet.UU.NET
|
|
Subject: Re: /etc and /usr/etc [was re: Seen in comp.os.minix]
|
|
Cc: linux-standards@concert.net
|
|
|
|
>> In retrospect I also think that /bin/init is a bad idea, but then it should
|
|
>> be /lib/init.
|
|
|
|
>Agreed.
|
|
|
|
>> ...../lib should contrain libraries, support files *and* executables which
|
|
>> shouldn't be in anyones path.
|
|
Agreed :-) The trick is to minimize what is in the device or partition of a
|
|
device that contains root (/). /lib should therefore contain only the minimal
|
|
stuff to allow a system to run. Same for /etc and /bin. Just enough to let the
|
|
system repair itself. Symlink the rest if it pleases, but it is really a bad
|
|
idea to set up a system that requires itself to be whole to make itself whole.
|
|
|
|
Or maybe rename it from linux to catch22ix :-)
|
|
|
|
Seriously, from a practical standpoint, what I'd like to be able to do is
|
|
|
|
1) Boot a WRITE-PROTECTED diskette.
|
|
2) Futz with my hard drive(s) from said standalone diskette system to set
|
|
'em up, format, partition, mkfs, mount and such.
|
|
3) Use some simple utility like tar to suck the rest of a distribution from
|
|
diskette, tape if I'm lucky, or network if I'm luckier.
|
|
4) Reboot from the hard drive.
|
|
5) Merrily configure my system and do useful work...
|
|
|
|
I'd be disappointed if a Draft didn't take such considerations to heart.
|
|
|
|
>>
|
|
>> And with this small change I'd like to see the Draft accepted.
|
|
|
|
>Agreed. I will make the change. All in favor? All opposed? Good.
|
|
>It passes. (seriously, one last day to bring up comments).
|
|
Disagreed :-)
|
|
|
|
This ignores a common use of init to change run states. As such it should
|
|
probably live not in /lib. I think that /etc/init is a better place. Not
|
|
that it matters all that much when source for everything is to be the norm.
|
|
If I think that my way is better, why then, I'll just go change things. That's
|
|
the code of the West :-)
|
|
--
|
|
Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265
|
|
Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121
|
|
The opinion(s) expressed above are mine and not those of my employer.
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Feb 21 14:31:07 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <26767-0@banjo.concert.net>; Fri, 21 Feb 1992 14:30:32 -0500
|
|
Received: from relay2.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91)
|
|
id AA02707; Fri, 21 Feb 92 14:30:29 -0500
|
|
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET
|
|
with SMTP (5.61/UUNET-internet-primary) id AA18265;
|
|
Fri, 21 Feb 92 14:30:29 -0500
|
|
Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail)
|
|
id 142908.25885; Fri, 21 Feb 1992 14:29:08 EST
|
|
Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA28059;
|
|
Fri, 21 Feb 92 10:10:58 PST
|
|
Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA05315;
|
|
Fri, 21 Feb 92 10:09:15 PST
|
|
Date: Fri, 21 Feb 92 10:09:15 PST
|
|
From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy)
|
|
Message-Id: <9202211809.AA05315@optisun17.optigfx.com>
|
|
To: uunet!athena.mit.edu!tytso@uunet.UU.NET
|
|
Subject: Re: Seen in comp.os.minix
|
|
Cc: linux-standards@concert.net
|
|
|
|
You hide all the definitions for weirdo disks and such under /dev/dsk/ and
|
|
/dev/rdsk/, and wierdo tapes under /dev/mt/ and then link the /dev/hd0
|
|
(or equivalent) to the /dev/dsk/0s4 (or equivalent) and link /dev/tape
|
|
to /dev/mt/9tr1600snr (or some such where the major/minor lets me talk to
|
|
my 9track1600bpi in non-rewind streaming modeu. Then you can to refer to
|
|
/dev/tape instead of having to diddle with mknod when you do things like
|
|
change to a cartridge tape drive. Make sense?
|
|
--
|
|
Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265
|
|
Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121
|
|
The opinion(s) expressed above are mine and not those of my employer.
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Feb 21 20:21:21 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <08476-0@banjo.concert.net>; Fri, 21 Feb 1992 20:21:07 -0500
|
|
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com)
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA05229;
|
|
Fri, 21 Feb 92 20:21:03 -0500
|
|
Received: by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA16586;
|
|
Fri, 21 Feb 1992 20:20:51 -0500
|
|
Received: by ponds.UUCP (smail2.5) id AA09789; 21 Feb 92 06:37:13 EST (Fri)
|
|
To: dg-rtp!banjo.concert.net!linux-standards-request@concert.net,
|
|
dws@engr.uark.edu
|
|
Subject: re: Seen in comp.os.minix
|
|
Cc: linux-standards@concert.net
|
|
Message-Id: <9202210637.AA09785@ponds.UUCP>
|
|
Date: 21 Feb 92 06:37:13 EST (Fri)
|
|
From: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers)
|
|
|
|
> > I completely agree with having just admin. files in /etc and executables in
|
|
> > /usr/etc.
|
|
>
|
|
> Ok, put init in /usr/etc, and make sure /usr is mounted just before you
|
|
> exec it.
|
|
>
|
|
> Minor problem.
|
|
>
|
|
|
|
I don't agree here, putting init in /usr/etc and "making sure /usr is
|
|
mounted" is not a "minor problem", especially considering a networked
|
|
environment (in some newer UNIXs /usr isn't actually on a local drive,
|
|
/usr/xxxx where xxxxx is anything but "local" isn't on a local drive.)
|
|
|
|
In my opinion, SUN, et. al. have gone a long way in solving these issues
|
|
with the /var directory, etc... we should *seriously* look at what they
|
|
did, why they did it, before we re-invent the wheel...
|
|
|
|
- Dave Rivers -
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Feb 27 10:06:58 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <22771-0@banjo.concert.net>; Thu, 27 Feb 1992 10:06:23 -0500
|
|
Subject: Third Draft Soon.
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Thu, 27 Feb 92 10:06:20 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
I must regret my heavy work-load cutting into my Linux activities. I will
|
|
shortly be distributing the THIRD draft, including changes to allow
|
|
'administrative binaries' to live in /etc, and 'binaries required to support
|
|
programs residing in /usr/bin' to reside in /usr/lib.
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Feb 28 07:08:12 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP)
|
|
id <24585-0@banjo.concert.net>; Fri, 28 Feb 1992 06:25:59 -0500
|
|
Received: from bentley.daimi.aau.dk by daimi.aau.dk
|
|
with SMTP (5.61++/IDA-1.2.8) id AA09668;
|
|
Fri, 28 Feb 92 12:25:47 +0100
|
|
Received: by bentley.daimi.aau.dk (5.64/1.34) id AA14724;
|
|
Fri, 28 Feb 92 12:25:44 +0100
|
|
Date: Fri, 28 Feb 92 12:25:44 +0100
|
|
From: tthorn@daimi.aau.dk
|
|
Message-Id: <9202281125.AA14724@bentley.daimi.aau.dk>
|
|
To: abc@banjo.concert.net
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: Alan B Clegg's message of Thu, 27 Feb 92 10:06:20 EST <9202271507.AA12216@daimi.aau.dk>
|
|
Subject: Third Draft Soon.
|
|
|
|
Good!! This ought to be acceptable to everybody.
|
|
|
|
/Tommy
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 3 13:02:51 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from nec-gw.nec.com by banjo.concert.net with SMTP (PP)
|
|
id <02528-0@banjo.concert.net>; Tue, 3 Mar 1992 13:02:37 -0500
|
|
Received: by nec-gw.nec.com (5.61+++/YDL1.7-911107.16)
|
|
id AA20546(nec-gw.nec.com ); Tue, 3 Mar 92 10:12:35 -0800
|
|
Received: by sj.nec.com (5.61+++/901019) id AA10636(netkeeper.sj.nec.com);
|
|
Tue, 3 Mar 92 10:12:32 -0800
|
|
Received: from necscc.cl.nec.co.jp
|
|
by necspl.ccs.mt.nec.co.jp (4.0/6.4J.6-NEC021) id AA17682;
|
|
Mon, 2 Mar 92 11:29:54 JST
|
|
Received: from nsis.cl.nec.co.jp by necscc.cl.nec.co.jp (4.1/6.4J.6) id AA20897;
|
|
Mon, 2 Mar 92 11:31:51 JST
|
|
Received: by nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-MX1.20) id AA24730;
|
|
Mon, 2 Mar 92 11:29:47 JST
|
|
Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.0) id AA04174;
|
|
Mon, 2 Mar 92 11:28:25 JST
|
|
Date: Mon, 2 Mar 92 11:28:25 JST
|
|
From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol)
|
|
Return-Path: <nick@nsis.cl.nec.co.jp>
|
|
Message-Id: <9203020228.AA04174@silk1.nsis.cl.nec.co.jp>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: International display
|
|
|
|
Just for your information. A group of us in Japan are planning to port Linux
|
|
to the more popular machines here. This will mean rewriting the drivers,
|
|
etc. If anyone has any ideas for an international console device driver, let
|
|
me know. At the moment, we are thinking of supporting EUC or JIS-7.
|
|
|
|
nick
|
|
|
|
|
|
From Linux-standards-request@banjo.concert.net Wed Mar 4 02:29:20 1992
|
|
Return-Path: <Linux-standards-request@banjo.concert.net>
|
|
Received: from van-bc.wimsey.bc.ca by banjo.concert.net with SMTP (PP)
|
|
id <03463-0@banjo.concert.net>; Wed, 4 Mar 1992 02:28:47 -0500
|
|
Received: by wimsey.bc.ca (/\==/\ Smail3.1.22.1 #22.7 sendmail)
|
|
id <m0lLqOz-0000RaC@wimsey.bc.ca>; Tue, 3 Mar 92 23:28 PST
|
|
Message-Id: <m0lLqOz-0000RaC@wimsey.bc.ca>
|
|
From: stewart@wimsey.bc.ca (Jim Stewart)
|
|
Subject: Some Concerns
|
|
To: Linux-standards@banjo.concert.net
|
|
Date: Tue, 3 Mar 92 23:28:37 PST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
|
|
I have a couple of concerns about the implementation of ps on
|
|
tsx-11.mit.edu. The work done is of high quality, and returns
|
|
handy information, *however*:
|
|
|
|
1) The use of a ps specific database of kernel symbols is IMHO a mistake.
|
|
I prefer to use nlist and the system image. I do not intend to boot
|
|
from floppy forever, and if the image is available I vote that it be
|
|
used.
|
|
|
|
2) The number of patches to the kernel required to support instrumentation
|
|
for this command scares me. I am uncomfortable with the notion of adding
|
|
individual fields to to the structures in an ad hoc fashion.
|
|
|
|
With respect to the first point:
|
|
|
|
+ I think that an official decision must be made soon as to the name
|
|
of the system image in the root directory.
|
|
|
|
+ Second, the default for the linux Makefile build should be changed
|
|
to NOT strip symbols.
|
|
|
|
+ Third, <nlist.h> and nlist(3) should be added to libc.a in the standard
|
|
distribution.
|
|
|
|
With respect to the second point:
|
|
|
|
+ A small collection of standard structures can be defined for
|
|
performance metering:
|
|
|
|
- struct vmmeter {...} and <sys/vmmeter.h> for memory
|
|
- struct psmeter {...} and <sys/psmeter.h> for tasks
|
|
- struct iometer {...} and <sys/iometer.h> for io
|
|
- ?
|
|
|
|
+ The goal of this work should be to localize changes to the kernel
|
|
for performance monitoring, with an eye to adding both conditional
|
|
inclusion and syscall access to this information.
|
|
|
|
If we do not do something about this now, we can expect a proliferation
|
|
of incompatible "sbin" utilities that will be so patch level dependent
|
|
as to be of little use to the general community.
|
|
|
|
js
|
|
|
|
From Linux-standards-request@banjo.concert.net Sun Mar 8 04:15:42 1992
|
|
Return-Path: <Linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <10504-0@banjo.concert.net>; Sun, 8 Mar 1992 04:15:23 -0500
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <15825-0@sun2.nsfnet-relay.ac.uk>; Sat, 7 Mar 1992 21:44:39 +0000
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa01361;
|
|
7 Mar 92 21:45 GMT
|
|
Date: Sat, 07 Mar 92 21:40:33 +0000
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: Linux-standards@banjo.concert.net
|
|
Subject: Small suggestion.... :-)
|
|
|
|
I spent a bit of time porting stuff this weekend. The various problems I
|
|
had suggested to me that there must be a way to make things easyer.
|
|
|
|
What I mean is that all people around is sayng: This is missing, this is
|
|
not standard SYSV, this has to be added.
|
|
|
|
To who should this be directed ?
|
|
To Linux ?
|
|
To the linux-standards ?
|
|
|
|
Who decides if /unix is /unix or /linux ?
|
|
It is useful to know it so you can count on something when you start coding !
|
|
|
|
Damiano
|
|
|
|
P.S. When will the tree structure be published ?
|
|
Can /unix be put in the tree structure ?
|
|
( I am against of reinventing new names for old things )
|
|
|
|
From Linux-standards-request@banjo.concert.net Sun Mar 8 10:58:07 1992
|
|
Return-Path: <Linux-standards-request@banjo.concert.net>
|
|
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
|
|
id <10703-0@banjo.concert.net>; Sun, 8 Mar 1992 10:57:48 -0500
|
|
Received: by sumax.seattleu.edu id AA02939 (5.65a/IDA-1.4.2
|
|
for Linux-standards@banjo.concert.net); Sun, 8 Mar 92 08:00:48 -0800
|
|
Date: Sun, 8 Mar 92 08:00:48 -0800
|
|
From: Chuck Boyer <boyer@sumax.seattleu.edu>
|
|
Message-Id: <9203081600.AA02939@sumax.seattleu.edu>
|
|
To: Linux-standards@banjo.concert.net, db1@ukc.ac.uk
|
|
Subject: Re: Small suggestion.... :-)
|
|
|
|
Linus himself should decide what basic tree structure is used in Linux
|
|
and let all others restructure according to their needs. When they publish
|
|
a 'port' of some program they should designate what tree structure they
|
|
use in a readme file.
|
|
chuck
|
|
|
|
From Linux-standards-request@banjo.concert.net Sun Mar 8 11:29:26 1992
|
|
Return-Path: <Linux-standards-request@banjo.concert.net>
|
|
Received: from kruuna.Helsinki.FI by banjo.concert.net with SMTP (PP)
|
|
id <10739-0@banjo.concert.net>; Sun, 8 Mar 1992 11:29:10 -0500
|
|
Received: by kruuna.helsinki.fi id AA22422 (5.65c/IDA-1.4.4
|
|
for Linux-standards@banjo.concert.net);
|
|
Sun, 8 Mar 1992 18:29:04 +0200
|
|
Date: Sun, 8 Mar 1992 18:29:04 +0200
|
|
From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi>
|
|
Message-Id: <199203081629.AA22422@kruuna.helsinki.fi>
|
|
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
|
|
To: Linux-standards@banjo.concert.net
|
|
Subject: Re: Small suggestion.... :-)
|
|
|
|
Chuck Boyer: "Re: Small suggestion.... :-)" (Mar 8, 8:00):
|
|
> Linus himself should decide what basic tree structure is used in Linux
|
|
> and let all others restructure according to their needs. When they publish
|
|
> a 'port' of some program they should designate what tree structure they
|
|
> use in a readme file.
|
|
|
|
Thanks for the vote of confidence, but I feel that this kind of standard
|
|
is something I need not decide: the last draft I saw looked nice, and as
|
|
long as it's simple and relatively standard, I'll go along. The
|
|
discussion on the directory structure seemed to be well enough thought
|
|
out, and all the points I ever wanted to say came up in mails by others.
|
|
There was a lot of "noise", but the result looked simple and workable.
|
|
I don't see why that couldn't be accepted as "final" - if there are
|
|
major problems we can always make changes later, but I wouldn't think
|
|
that would be needed.
|
|
|
|
I'm also more than happy enough to see that people are ready to engage
|
|
in this kind of discussion: I'm mostly interested in the kernel proper,
|
|
and I feel user-level (even if the user is root) things are better
|
|
decided by people who use the system. I'd rather just make the /really/
|
|
low-level things available: the kernel and the root-image. If the rest
|
|
of the distribution can be organized some other way (ABC-release), I'll
|
|
be very happy indeed.
|
|
|
|
Linus
|
|
|
|
From Linux-standards-request@banjo.concert.net Sun Mar 8 11:50:31 1992
|
|
Return-Path: <Linux-standards-request@banjo.concert.net>
|
|
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
|
|
id <10775-0@banjo.concert.net>; Sun, 8 Mar 1992 11:50:15 -0500
|
|
Received: by sumax.seattleu.edu id AA04346 (5.65a/IDA-1.4.2
|
|
for Linux-standards@banjo.concert.net); Sun, 8 Mar 92 08:53:17 -0800
|
|
Date: Sun, 8 Mar 92 08:53:17 -0800
|
|
From: Chuck Boyer <boyer@sumax.seattleu.edu>
|
|
Message-Id: <9203081653.AA04346@sumax.seattleu.edu>
|
|
To: Linux-standards@banjo.concert.net, torvalds@cc.helsinki.fi
|
|
Subject: Re: Small suggestion.... :-)
|
|
|
|
Okay. I/we are so grateful for your kernel/root-image Linux flavour of
|
|
unix for our hot new 386/486 boxes, all of the great work. Thankyou.
|
|
Okay for the 'standard' of the tree structure having been set and published
|
|
by others. Where is it, by the way? Will it be published in the FAQ, with
|
|
the new 13 version of Linux (out soon), or where?
|
|
|
|
I, by the way, am working on a text file (plain text with tabs, no
|
|
nroff, troff, Tex, etc.) on explaining for 'beginners' just exactly what
|
|
everything is pertaining to Linux on the ftp site tsx-11.
|
|
|
|
INSTALL
|
|
>these are the 1) Linux operating system itself; a) bootimage/version#,
|
|
>and b) rootimage/version#, 2) rawrite (program to be used in DOS environ-
|
|
>ment to transfer root/boot image files to floppies, 3) edpart, pdisk
|
|
>(hard-disk partition programs used in DOS environment to set up partitions).
|
|
|
|
bootimage-0.12.Z
|
|
partition-programs/
|
|
rawrite.c
|
|
rawrite.doc
|
|
rawrite.exe
|
|
rootimage-0.12.Z
|
|
|
|
INSTALL/partition-programs:
|
|
edpart.arc
|
|
edpart.doc
|
|
pdisk.arc
|
|
pdisk.doc
|
|
-----------------------etc....
|
|
|
|
I am willing to go through the whole thing and set it up like this.
|
|
The reasoning is that I, and perhaps others as well, get very tired
|
|
typing out the same answers/responses over and over again. Actually,
|
|
I need to hand hold a friend here at sumax and I'd like to make it
|
|
available to the net.
|
|
Any suggestions?
|
|
chuck
|
|
|
|
From Linux-standards-request@banjo.concert.net Sun Mar 8 22:55:21 1992
|
|
Return-Path: <Linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <11241-0@banjo.concert.net>; Sun, 8 Mar 1992 22:55:03 -0500
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <2227-0@sun2.nsfnet-relay.ac.uk>; Mon, 9 Mar 1992 01:12:26 +0000
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa02418;
|
|
8 Mar 92 18:34 GMT
|
|
Date: Sun, 08 Mar 92 18:31:40 +0000
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: Linux-standards@banjo.concert.net
|
|
Subject: Re: Small suggestion (boyer)
|
|
|
|
Ok, Then when there is something missing
|
|
( some library function or some include non "standard" )
|
|
should we send a request to him ?
|
|
|
|
During my porting I found some bits bissing. Should I mail to
|
|
Linux or would it be better to have an organization where one
|
|
person is responsabile for include, one for the libraryes,
|
|
one for the kernel ( Linux ).. and so on...
|
|
|
|
Anyway, when is the new version of linux going to be released ?
|
|
|
|
Damiano
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 9 00:30:10 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from nec-gw.nec.com by banjo.concert.net with SMTP (PP)
|
|
id <11302-0@banjo.concert.net>; Mon, 9 Mar 1992 00:29:54 -0500
|
|
Received: by nec-gw.nec.com (5.61+++/YDL1.7-911107.16)
|
|
id AA18023(nec-gw.nec.com ); Sun, 8 Mar 92 21:40:49 -0800
|
|
Received: by sj.nec.com (5.61+++/901019) id AA27743(netkeeper.sj.nec.com);
|
|
Sun, 8 Mar 92 21:40:42 -0800
|
|
Received: from necscc.cl.nec.co.jp
|
|
by necspl.ccs.mt.nec.co.jp (4.0/6.4J.6-NEC021) id AA12640;
|
|
Mon, 9 Mar 92 14:29:32 JST
|
|
Received: from nsis.cl.nec.co.jp by necscc.cl.nec.co.jp (4.1/6.4J.6) id AA06482;
|
|
Mon, 9 Mar 92 14:28:33 JST
|
|
Received: by nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-MX1.20) id AA11404;
|
|
Mon, 9 Mar 92 14:29:50 JST
|
|
Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.0) id AA08408;
|
|
Mon, 9 Mar 92 14:28:26 JST
|
|
Date: Mon, 9 Mar 92 14:28:26 JST
|
|
From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol)
|
|
Return-Path: <nick@nsis.cl.nec.co.jp>
|
|
Message-Id: <9203090528.AA08408@silk1.nsis.cl.nec.co.jp>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: ETA & standards
|
|
|
|
I too, would like to know when the ETA for the
|
|
next version is. The group who want to port
|
|
Linux to the Japanese computers are waiting for
|
|
version 0.13 before starting. Also, is anyone
|
|
interested in creating an "international"
|
|
Linux standard?
|
|
|
|
nick
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 9 09:25:30 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
|
|
id <12057-0@banjo.concert.net>; Mon, 9 Mar 1992 09:25:13 -0500
|
|
Received: by sumax.seattleu.edu id AA09338 (5.65a/IDA-1.4.2
|
|
for linux-standards@banjo.concert.net); Mon, 9 Mar 92 06:28:16 -0800
|
|
Date: Mon, 9 Mar 92 06:28:16 -0800
|
|
From: Chuck Boyer <boyer@sumax.seattleu.edu>
|
|
Message-Id: <9203091428.AA09338@sumax.seattleu.edu>
|
|
To: linux-standards@banjo.concert.net, nick@nsis.cl.nec.co.jp
|
|
Subject: Re: ETA & standards
|
|
|
|
BTW, when are the standards going to be posted, or when are we going to
|
|
be reminded of where they are?
|
|
chuck
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 9 09:35:54 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <12110-0@banjo.concert.net>; Mon, 9 Mar 1992 09:35:39 -0500
|
|
Subject: Revision 1.0 posted to alt.os.linux
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Mon, 9 Mar 92 9:35:37 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
Revision 1.0 (following Draft 2) of the Directory Structure document has been
|
|
posted to alt.os.linux.
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 9 11:10:20 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
|
|
id <14772-0@banjo.concert.net>; Mon, 9 Mar 1992 11:09:01 -0500
|
|
Received: by sumax.seattleu.edu id AA02986 (5.65a/IDA-1.4.2
|
|
for linux-standards@banjo.concert.net); Mon, 9 Mar 92 08:12:00 -0800
|
|
Date: Mon, 9 Mar 92 08:12:00 -0800
|
|
From: Chuck Boyer <boyer@sumax.seattleu.edu>
|
|
Message-Id: <9203091612.AA02986@sumax.seattleu.edu>
|
|
To: abc@banjo.concert.net, linux-standards@banjo.concert.net
|
|
Subject: Re: Revision 1.0 posted to alt.os.linux
|
|
|
|
Revision 1.0 (following Draft 2) of the Directory Structure document has been
|
|
posted to alt.os.linux.
|
|
|
|
thanks, I was asking Linux yesterday and he didn't know where they were
|
|
either.
|
|
chuck
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 10 14:29:34 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <18798-0@banjo.concert.net>; Tue, 10 Mar 1992 14:29:03 -0500
|
|
Subject: Greetings, and welcome to phase 2.
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Tue, 10 Mar 92 14:28:56 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
Well, with the publication of the File Systems Document, the Standards Mailing
|
|
list has grown by about 15 people today alone.
|
|
|
|
Since there is no current discussion, I will start some.
|
|
|
|
I am preparing the ABC-Release of 0.95, and am looking for the *LATEST*
|
|
versions of the following:
|
|
|
|
usr.bin sources [Are there changes since *.12?]
|
|
usr.lib sources "
|
|
library sources "
|
|
Compiler (1.40/2.00) with and without FP support.
|
|
Gnu Utilities (Compiled with latest libraries/compiler)
|
|
SCSI drive for AHA-1542 that works under .95 (no, I have not tested
|
|
the old one yet, since I don't have
|
|
the latest compiler yet)
|
|
|
|
I have looked at the MIT and funet archives, and they are in a bad state of
|
|
repair, with many versions of the same things and many patches that don't
|
|
quite fit the current version, etc...
|
|
|
|
I have also restarted the banjo FTP archive mirrors, so if banjo.concert.net
|
|
is closer to you than to any of the other archives, you might want to check
|
|
here...
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Mar 11 16:41:56 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from dragonfly.wri.com by banjo.concert.net with SMTP (PP)
|
|
id <24185-0@banjo.concert.net>; Wed, 11 Mar 1992 16:41:42 -0500
|
|
Received: from fishy.wri.com by dragonfly.wri.com with SMTP
|
|
id AA25631 (5.65c/IDA-1.4.4 for <linux-standards@banjo.concert.net>);
|
|
Wed, 11 Mar 1992 15:41:38 -0600
|
|
Return-Path: <dugan>
|
|
From: dugan@wri.com
|
|
Message-Id: <9203112128.AA12169@fishy.wri.com>
|
|
Subject: ABC Release
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Wed, 11 Mar 92 15:28:02 CST
|
|
In-Reply-To: <9203101950.AA04738@archimedes.math.uiuc.edu>; from "Alan B Clegg" at Mar 10, 92 2:28 pm
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
I am all for this, it is hard to know what the most current
|
|
versions of things are, and is also a pain to have to get 500
|
|
different files to make a complete Linux system.
|
|
|
|
It would be nice to have a listing of the latest versions of each
|
|
part of Linux. Also, has anyone tried to implement mail for Linux
|
|
at all? especically uucp & local mail? If not does anyone know of
|
|
any possible source to try to port?
|
|
|
|
Jon
|
|
--
|
|
Jon Dugan (dugan@wri.com) - SQA Group
|
|
Wolfram Research, Inc. 217/398-0700
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Mar 12 07:10:41 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from jazz.concert.net by banjo.concert.net with SMTP (PP)
|
|
id <25326-0@banjo.concert.net>; Thu, 12 Mar 1992 07:10:23 -0500
|
|
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com)
|
|
by jazz.concert.net (5.59/tas-concert/6-19-91) id AA25900;
|
|
Thu, 12 Mar 92 07:10:16 -0500
|
|
Received: by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA04920;
|
|
Thu, 12 Mar 1992 07:10:14 -0500
|
|
Received: by ponds.UUCP (smail2.5) id AA02757; 12 Mar 92 07:04:48 EST (Thu)
|
|
To: linux-standards@concert.net
|
|
Subject: Re: uucp.
|
|
Message-Id: <9203120704.AA02753@ponds.UUCP>
|
|
Date: 12 Mar 92 07:04:48 EST (Thu)
|
|
From: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers)
|
|
|
|
|
|
I have been working on taylor-uucp for some time, and have been
|
|
getting closer-and-closer.
|
|
|
|
I can get a chat going, and the first shere=.... but the conversation
|
|
eventually locks up.
|
|
|
|
But - I have been working with version 0.12; and haven't had time
|
|
to try 0.95 - which could possibly be better.
|
|
|
|
- Dave Rivers -
|
|
(rivers@ponds.uucp)
|
|
|
|
From linux-standards-request@banjo.concert.net Sat Mar 14 00:37:29 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from JARTHUR.CLAREMONT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <14789-0@banjo.concert.net>; Sat, 14 Mar 1992 00:36:57 -0500
|
|
Date: Fri, 13 Mar 92 21:34:55 PST
|
|
From: "Jim Winstead Jr." <jwinstea@jarthur.Claremont.EDU>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Linux v0.95a and the ABC-Release
|
|
|
|
|
|
The release of Linux v0.95a, which is expected sometime next week,
|
|
will be handled a little differently than past releases. After a
|
|
little bit of discussion with Linus, I have agreed to take over the
|
|
distribution of the root-system diskette.
|
|
|
|
What does this mean? Well, for one thing, the ABC-Release may become
|
|
obsolete real fast, since I have spent a good deal of time
|
|
restructuring the root floppy towards the released Linux Directory
|
|
Structure Standard (I don't believe this is the original name, but
|
|
it's what I have since dubbed it - I think it was called the Linux
|
|
File System Standard, which could cause possible confusion once a
|
|
Linux File System is defined to replace the current Minix one.
|
|
Besides, it really defines the Directory Structure, not the File
|
|
System.)
|
|
|
|
I have spent some time pouring through the back archives of the
|
|
standards mailing list, and the LDS-Standard, and have a few questions
|
|
for the members of this esteemed committee. (:
|
|
|
|
1) Has a place been decided for init, update, swapon, mkfs,
|
|
mknod, and other such administrative utilities? From all the
|
|
indications I've seen, /etc looks like the place to put them.
|
|
|
|
What about other daemons? (cron comes to mind, especially.)
|
|
|
|
/usr/etc is WRONG! /etc/rc is started by init. /usr may be
|
|
mounted in rc. How can /usr/etc/init run /rc if /usr hasn't
|
|
been mounted yet?
|
|
|
|
2) I've renamed agetty to getty. This fits in with keeping the
|
|
standard names for the standard unix utilites, even if they've
|
|
been gleaned from sources that used different names to avoid
|
|
conflict. (i.e. the GNU stuff.)
|
|
|
|
3) Where should programs like doshell and setterm go? These are
|
|
Linux-specific, and my reading of the LDS-Standard has them
|
|
fitting into /usr/bin/local, which seems very odd. Would they
|
|
make more sense in /usr/bin?
|
|
|
|
4) Something that will be on the root diskette, and may warrant
|
|
mention in the LDS-Standard is a directory called /INSTALL
|
|
where some documentation and installation scripts will go.
|
|
Is there a better place for this? (Perhaps something special
|
|
under /usr/man? /usr/man/INSTALL?)
|
|
|
|
5) Do we want to see a /var tree? I like the idea, personally.
|
|
|
|
6) Here is the current tree structure on my root disk:
|
|
|
|
|
|
.--------+-dev
|
|
+-usr------+-bin
|
|
| +-adm
|
|
| +-etc
|
|
| +-spool
|
|
| +-local----+-bin
|
|
| | +-etc
|
|
| | +-lib
|
|
| | +-man
|
|
| | +-src
|
|
| +-lib
|
|
| +-man
|
|
| +-include
|
|
| +-src------+-bin
|
|
| | +-lib
|
|
| | +-linux
|
|
| | +-usr.bin
|
|
| | +-usr.lib
|
|
| +-tmp
|
|
+-bin
|
|
+-etc
|
|
+-tmp
|
|
+-mnt
|
|
+-home
|
|
+-lib
|
|
+-INSTALL
|
|
|
|
As you might have guessed, a large part of this is just tree.
|
|
/usr/local is all empty, /usr/bin has very few files in it, and
|
|
/mnt, /lib, /home, and /tmp are empty.
|
|
|
|
The bulk of the files are in /bin, with all the devices in
|
|
/dev, obviously. /etc also contains some barebones config
|
|
files. (passwd, profile, rc, etc.)
|
|
|
|
7) tar and compress are in /bin, since they are necessary to the
|
|
restoring of a toasted partition. (gotta get the backups
|
|
somewhere!) Make sense to everyone?
|
|
|
|
*) What do people think of a few shell scripts, such as 'mktree',
|
|
'mkdev', 'install', etc, as part of the /INSTALL directory?
|
|
|
|
mktree would create a blank directory tree on a clean
|
|
partition, mkdev would create the standard devices (similar to
|
|
the MAKEDEV suggestion made by someone earlier.) and install
|
|
would copy over the files from the root floppy to a partition
|
|
mounted on /mnt (or specified, if the root floppy is mounted as
|
|
/mnt instead of being booted from.)
|
|
|
|
If anyone is willing to write these, go ahead and send
|
|
something to me. Be forewarned that it will probably be
|
|
hacked up a fair bit to fit with what I already have.
|
|
|
|
I'll cut myself off here, to collect my thoughts some more and give
|
|
you plenty of time for feedback. I expect the release of 0.95a by the
|
|
end of next week at the absolute latest, with early next week as more
|
|
likely, so go ahead and flood my mailbox.
|
|
|
|
(Also, at least until Monday, cc: your messages to the Linux Standards
|
|
list concering this to me as well, in case abc doesn't get around to
|
|
adding me to the list until next Monday.)
|
|
--
|
|
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 linux-standards-request@banjo.concert.net Sat Mar 14 01:22:04 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from TSX-11.MIT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <14871-0@banjo.concert.net>; Sat, 14 Mar 1992 01:21:38 -0500
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA01337;
|
|
Sat, 14 Mar 92 01:21:27 -0500
|
|
Date: Sat, 14 Mar 92 01:21:27 -0500
|
|
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
|
|
Message-Id: <9203140621.AA01337@tsx-11.MIT.EDU>
|
|
To: "Jim Winstead Jr." <jwinstea@jarthur.Claremont.EDU>
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: jwinstea@jarthur.Claremont.EDU's message of Fri, 13 Mar 92 21:34:55 PST, <9203140537.AA26470@Athena.MIT.EDU>
|
|
Subject: Re: Linux v0.95a and the ABC-Release
|
|
Reply-To: tytso@athena.mit.edu
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
Well, your comments look on target to me, as far as the structure on the
|
|
Root-system diskette. At least as far as my imaging of what the ABC
|
|
release is all about, I don't think that it necessarily obsoletes it.
|
|
My vision of the ABC-release is that it would be a large, comprehensive
|
|
release of binaries and sources for Linux, so we're talking about a file
|
|
hierarchy much larger than the 1.2 meg root image floppy. The keeper of
|
|
this release would worry about getting the latest sources from authors,
|
|
making sure that utilities such as "ps" work with the latest kernel that
|
|
has been released, etc., etc. Of course, that's my vision only. You
|
|
should ask other people, in particular Alan Clegg (abc@concert.net) if
|
|
that's what they had in mind when they saw the words "ABC Release".
|
|
|
|
- Ted
|
|
|
|
From linux-standards-request@banjo.concert.net Sat Mar 14 01:47:27 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from JARTHUR.CLAREMONT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <14917-0@banjo.concert.net>; Sat, 14 Mar 1992 01:47:10 -0500
|
|
Date: Fri, 13 Mar 92 22:46:01 PST
|
|
From: "Jim Winstead Jr." <jwinstea@jarthur.Claremont.EDU>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: A Small Correction
|
|
|
|
|
|
I said something silly about my root-floppy distribution "obsoleting"
|
|
the ABC-Release. This is a case of my brain skipping a few steps in
|
|
drawing some conclusions, and Ted (tytso) has straightened me out on
|
|
these.
|
|
|
|
ABC-Release: Big distribution/organization of binaries and sources.
|
|
This would include much of the /usr tree.
|
|
|
|
Linux 0.95a: Boot (by Linus) and Root (by me) floppies with the bare
|
|
minimum needed for installing Linux on a system. This
|
|
would include, besides the kernel, most of the stuff
|
|
you'd find on the root partition. (/bin, /etc, /dev,
|
|
and maybe in the future, /lib - shared libs!)
|
|
|
|
(A note on the bit about shared libs - definitely not in 0.95a, since
|
|
gcc 2.0 with shared libs is still in the alpha stages. Once this hits
|
|
a release status, though, it will make the root floppy much easier to
|
|
fit things onto.)
|
|
|
|
This is, of course, only how I see things. If you think differently,
|
|
feel free to tell me. (And remember, I'm not on the list yet, so cc:
|
|
things to me if they pertain to what I say, at least for the time
|
|
being.)
|
|
--
|
|
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 linux-standards-request@banjo.concert.net Sun Mar 15 13:35:01 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <17422-2@banjo.concert.net>; Sun, 15 Mar 1992 13:34:26 -0500
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <8024-0@sun2.nsfnet-relay.ac.uk>; Sat, 14 Mar 1992 18:12:22 +0000
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa26713;
|
|
14 Mar 92 14:39 GMT
|
|
Date: Sat, 14 Mar 92 14:37:04 +0000
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: dugan@wri.com, linux-standards@banjo.concert.net
|
|
Subject: Re: ABC Release
|
|
|
|
This is what I meant when I posted the news about having a different
|
|
subtree for each release.
|
|
|
|
My idea is:
|
|
Put in each subtree the software the is NEW to that release !
|
|
Ex:
|
|
The new kernel
|
|
The new cc or libraries
|
|
New include, programs
|
|
|
|
So: If you want the latest stuff you get the latest release
|
|
and what you can't find in the latest release you may find in
|
|
the previous one.
|
|
|
|
This is simpler and clearer than having
|
|
a lot of
|
|
newgcc, newkernel..... ando also keep the naming consistent !
|
|
|
|
If you like it please post a news :-)
|
|
|
|
Damiano
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Mar 25 08:20:06 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <20181-0@banjo.concert.net>; Wed, 25 Mar 1992 08:03:35 -0500
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <8831-0@sun2.nsfnet-relay.ac.uk>; Tue, 24 Mar 1992 13:40:51 +0000
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa02208;
|
|
24 Mar 92 9:21 GMT
|
|
Date: Tue, 24 Mar 92 09:16:45 +0000
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Anybody willing to answer me ?
|
|
|
|
In the news article where I posted the bug fix for the pipe read
|
|
I asked if making a symlink from /usr/src/linux/include/linux
|
|
to /usr/include/linux is a valid action.
|
|
Nobody answered me....
|
|
|
|
I also asked why there are two set of includes ( one in /usr/include
|
|
and one in /usr/src/linux/include ) and if it is possible to merge them
|
|
Again, no answer.....
|
|
|
|
In another article I asked if anybody has any informations on the
|
|
Colorado QIC-10 tape drive or if anybody know where I can get any info.
|
|
No answer....
|
|
|
|
I begin to think that my university does not post my articles in the net
|
|
|
|
Anyway, anybody is willing to answer to at least one of the above
|
|
questions ?
|
|
|
|
Damiano
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Mar 25 08:51:36 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <20369-0@banjo.concert.net>; Wed, 25 Mar 1992 08:50:56 -0500
|
|
Subject: Re: Anybody willing to answer me ?
|
|
To: db1@ukc.ac.uk (Damiano Bolla)
|
|
Date: Wed, 25 Mar 92 8:50:53 EST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <no.id>; from "Damiano Bolla" at Mar 24, 92 9:16 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
In previous mail, Damiano Bolla said something like:
|
|
> In the news article where I posted the bug fix for the pipe read
|
|
> I asked if making a symlink from /usr/src/linux/include/linux
|
|
> to /usr/include/linux is a valid action.
|
|
> Nobody answered me....
|
|
|
|
I will answer. Yes. It is valid, and I have done it on my system, and
|
|
expect the ABC Release of Linux .95a to have symlinks as well.
|
|
|
|
BTW: Is anyone interested in contributing to the new release, or am I going
|
|
to have to get all the GNU stuff and do it myself? PLEASE HELP ME OUT!
|
|
We want Linux to be as easy as ABC, right? So-far I have recompiled bison,
|
|
gawk, and am working on the gnu fileutils (what was the resolution of the
|
|
missing ftruncate() call, anyway?)
|
|
|
|
> In another article I asked if anybody has any informations on the
|
|
> Colorado QIC-10 tape drive or if anybody know where I can get any info.
|
|
> No answer....
|
|
|
|
Don't have any info on this...
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Mar 25 09:49:42 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from FEDIX.FIE.COM by banjo.concert.net with SMTP (PP)
|
|
id <21237-0@banjo.concert.net>; Wed, 25 Mar 1992 09:49:20 -0500
|
|
Received: by fedix.fie.com id AA00197 (5.65c/IDA-1.4.4
|
|
for linux-standards@banjo.concert.net); Wed, 25 Mar 1992 14:50:00 GMT
|
|
Date: Wed, 25 Mar 1992 14:50:00 GMT
|
|
From: Mike Vore - W3CCV <mvore@fedix.fie.com>
|
|
Message-Id: <199203251450.AA00197@fedix.fie.com>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Colorado Tape support
|
|
|
|
|
|
> In another article I asked if anybody has any informations on the
|
|
> Colorado QIC-10 tape drive or if anybody know where I can get any info.
|
|
> No answer....
|
|
|
|
I just subscribed to l-a-s so I didn't see your previous postings, but I
|
|
had Coherent on my system for about a year before turning to Linux.
|
|
Maybe some hackers can get thru to CMS, or crack their code. I've
|
|
talked with both Coherent (Mark Williams Co.) and to CMS about the
|
|
problem. They have both shrugged their sholders and pointed the blame
|
|
on the other. Hopefully - as I said - some hacker can break the code
|
|
and get the CMS tape drives running under Linux.
|
|
- mike
|
|
|
|
-------------------------------------------------
|
|
Mike Vore, | Of course these are my thoughts,
|
|
SysManager | The company dosn't know what I'm
|
|
mvore@fedix.fie.com | thinking (or doing)
|
|
(voice) +1 (301)975-0103 |
|
|
-------------------------------------------------
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Mar 25 10:05:22 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
|
|
id <21318-0@banjo.concert.net>; Wed, 25 Mar 1992 10:05:01 -0500
|
|
Received: by sumax.seattleu.edu id AA12880 (5.65a/IDA-1.4.2
|
|
for linux-standards@banjo.concert.net); Wed, 25 Mar 92 06:00:47 -0800
|
|
Date: Wed, 25 Mar 92 06:00:47 -0800
|
|
From: Chuck Boyer <boyer@seattleu.edu>
|
|
Message-Id: <9203251400.AA12880@sumax.seattleu.edu>
|
|
To: db1@ukc.ac.uk, linux-standards@banjo.concert.net
|
|
Subject: Re: Anybody willing to answer me ?
|
|
|
|
Damiano;
|
|
I am a beginner/intermediate, so... watch out for my answers...
|
|
but...;
|
|
|
|
>In the news article where I posted the bug fix for the pipe read
|
|
>I asked if making a symlink from /usr/src/linux/include/linux
|
|
>to /usr/include/linux is a valid action.
|
|
>Nobody answered me....
|
|
|
|
I know that it is possible to make that kind of link, though I
|
|
do not know enough to say whether that is necessary. I did do
|
|
links in /usr/include to /usr/local/include for gcc stuff and
|
|
the compiler all of a sudden worked, it was hardcoded where
|
|
to find the stuff...
|
|
|
|
>I also asked why there are two set of includes ( one in /usr/include
|
|
>and one in /usr/src/linux/include ) and if it is possible to merge them
|
|
>Again, no answer.....
|
|
|
|
Same response.
|
|
|
|
>In another article I asked if anybody has any informations on the
|
|
>Colorado QIC-10 tape drive or if anybody know where I can get any info.
|
|
>No answer....
|
|
|
|
Way beyond my knowledge.
|
|
|
|
>I begin to think that my university does not post my articles in the net
|
|
|
|
If this article response gets to you then you are okay.
|
|
|
|
>Anyway, anybody is willing to answer to at least one of the above
|
|
>questions ?
|
|
|
|
I am willing to answer anything that I can.
|
|
|
|
>Damiano
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Mar 26 05:38:23 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP)
|
|
id <24843-0@banjo.concert.net>; Thu, 26 Mar 1992 05:38:04 -0500
|
|
Received: from austin.daimi.aau.dk by daimi.aau.dk with SMTP (5.61++/IDA-1.2.8)
|
|
id AA23079; Thu, 26 Mar 92 11:37:46 +0100
|
|
Received: by austin.daimi.aau.dk (5.64/1.34) id AA19568;
|
|
Thu, 26 Mar 92 11:37:43 +0100
|
|
Date: Thu, 26 Mar 92 11:37:43 +0100
|
|
From: tthorn@daimi.aau.dk
|
|
Message-Id: <9203261037.AA19568@austin.daimi.aau.dk>
|
|
To: abc@banjo.concert.net
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: Alan B Clegg's message of Wed, 25 Mar 92 8:50:53 EST <9203251443.AA20180@daimi.aau.dk>
|
|
Subject: Re: Anybody willing to answer me ?
|
|
|
|
BTW: Is anyone interested in contributing to the new release, or am I going
|
|
to have to get all the GNU stuff and do it myself? PLEASE HELP ME OUT!
|
|
|
|
I wanted to reply to your original message, but just didn't get around to it.
|
|
Yes, I think that the ABC-release is needed now more than ever. This mess
|
|
release without source cries out for the ABC-release.
|
|
|
|
I'm still moving my adaptec to drew's scsi, so I haven't been able to help,
|
|
but I expect to compile RCS-5.6 and more, and upload binaries *AND* diffs,
|
|
original source(?) *AND* explainations on how and with which libraries
|
|
it was compiled.
|
|
|
|
As the situation is now with gcc 2.0 and libraries (changing all the time),
|
|
we *really* need source and evt. diffs.
|
|
|
|
/Tommy
|
|
PS: Sorry for all you using the adaptec, but it should be there RSN.
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Mar 26 09:22:30 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <00307-0@banjo.concert.net>; Thu, 26 Mar 1992 09:22:03 -0500
|
|
Subject: Re: ABC Release
|
|
To: dugan@wri.com
|
|
Date: Thu, 26 Mar 92 9:21:59 EST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <9203112128.AA12169@fishy.wri.com>; from "dugan@wri.com" at Mar 11, 92 3:28 pm
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
In previous mail, dugan@wri.com said something like:
|
|
|
|
[ Regarding the ABC Release of Linux .95a ]
|
|
|
|
> I am all for this, it is hard to know what the most current
|
|
> versions of things are, and is also a pain to have to get 500
|
|
> different files to make a complete Linux system.
|
|
|
|
Yup. I have begun pulling down the sources *FROM PREP.AI.MIT.EDU* and
|
|
compiling, and I am *REALLY* impressed. Everything has been going relatively
|
|
well. I have the following packages completed:
|
|
|
|
gawk, bison, make, shellutils, textutils, gnugo, gnuchess
|
|
|
|
I am currently working on bash, but that is going slowly. I am waiting
|
|
with baited breath for the Adaptec SCSI drivers since I only have 40Meg of
|
|
IDE, and half a gig of SCSI.. I am running on *VERY* limited space right
|
|
now. I never realized just how big the GNU stuff really was...
|
|
|
|
Anyone wanting to work on parts, please let me know so we can coordinate!
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Sat Mar 28 07:31:33 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <09777-1@banjo.concert.net>; Sat, 28 Mar 1992 07:00:53 -0500
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <22806-0@sun2.nsfnet-relay.ac.uk>; Sat, 28 Mar 1992 00:32:11 +0000
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa19546;
|
|
27 Mar 92 15:59 GMT
|
|
Date: Fri, 27 Mar 92 15:52:20 +0000
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Thanks for the reply !
|
|
|
|
I want to thank everybody that answered me !
|
|
|
|
Sofar we know that
|
|
1) The include files in /usr/src/linux/include are the one
|
|
that are "important" and to be trusted.
|
|
|
|
2) The news system jammed my last post :-(
|
|
|
|
3) It is quite hard to find informations about the Colorado
|
|
QIC-10 ( the 120Mb tape )
|
|
|
|
5) I my past new I was posting a fix to the pipe read bug.
|
|
I sent the fix to linux. If he doesn't post a "better" version
|
|
of the fix I am going to try to code one :-)
|
|
|
|
6) I am tryng to play with the VGA switching mode...
|
|
I mean I am tryng to swithch the VGA between graphics and
|
|
text mode. I managed to put into the kernel the minix mgr code
|
|
and it seems to work (got it working this morning)
|
|
I was wondering if somwbody else is playng with this suff.....
|
|
( I am not using the BIOS I use direct VGA registers )
|
|
|
|
|
|
Anyway. I think I will use the maillist instead of the news. It seems
|
|
more reliable.
|
|
|
|
Damiano
|
|
|
|
P.S. About the naming of the devices.
|
|
I think that the MOST important thing of all is to get the STANDARD
|
|
in such a vay that it is expandible. I don't really care what it is
|
|
as long I don't have to change names each time we have
|
|
More Pty
|
|
More Hd
|
|
More Tapes
|
|
More Serials
|
|
More VirtualConsols
|
|
More VgaFramebuffers
|
|
.........
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 30 09:07:29 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <13747-0@banjo.concert.net>; Mon, 30 Mar 1992 09:07:14 -0500
|
|
Subject: Ok, we have been envoked.
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Mon, 30 Mar 92 9:07:11 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
erc@Apple.COM (Ed Carp) stated in a recent posting on device names:
|
|
|
|
=I understand, and agree with you, but I think that the standards folks should
|
|
=just choose a standard, and then people can do the "ln -s" dance to make
|
|
=them whatever they want to. What the standards for the name are, in my
|
|
=opinion, irrelevent, since one can always link them to something else.
|
|
=You wouldn't want to actually RENAME them, of course, because someone
|
|
=will most certainly write software to conform to the standard that you
|
|
=just changed (and broke their software in the process). For example,
|
|
=/dev/tty should remain /dev/tty, but if someone doesn't like it, they can
|
|
=always "ln -s /dev/tty /dev/mytty" or some such.
|
|
|
|
Ok, since the file system standard went over so well, I propose this
|
|
(open for discussion):
|
|
|
|
/dev/wd -- Western Digital and related disk controllers
|
|
/dev/wd0 -- entire disk 0
|
|
/dev/wd1 -- entire disk 1
|
|
/dev/wd01 -- disk 0, partition 1
|
|
--etc--
|
|
|
|
/dev/sd -- SCSI controllers
|
|
/dev/sd0 -- entire DEVICE 0
|
|
/dev/sd01 -- DEVICE 0, LUN 1
|
|
/dev/sd011 -- DEVICE 0, LUN 1, partition 1 [???]
|
|
--etc--
|
|
|
|
/dev/tty -- "your" tty
|
|
/dev/tty[a-d] -- com1 -> com4 [???]
|
|
[from SunOS]
|
|
/dev/ttyv[1-4] -- "virtual terminals" [???]
|
|
/dev/console -- /dev/ttyv1 [???]
|
|
/dev/ttyp[0-f] -- pseudo terminals
|
|
/dev/ttyq[0-f] pseudo terminals
|
|
|
|
/dev/lp[ab] -- lpt1, lpt2
|
|
|
|
Ok, now... DISCUSS IT... Let's set a date of.. oh.. Wednesday the 1st of
|
|
April as the date for the first draft...
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 30 10:51:26 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from p.lanl.gov by banjo.concert.net with SMTP (PP)
|
|
id <14161-0@banjo.concert.net>; Mon, 30 Mar 1992 10:44:08 -0500
|
|
Received: from zaphod.lanl.gov by p.lanl.gov (5.65/1.14) id AA06986;
|
|
Mon, 30 Mar 92 08:44:02 -0700
|
|
Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA00311;
|
|
Mon, 30 Mar 92 08:43:58 MST
|
|
Date: Mon, 30 Mar 92 08:43:58 MST
|
|
From: egdorf@zaphod.lanl.gov (Skip Egdorf)
|
|
Message-Id: <9203301543.AA00311@zaphod.lanl.gov.lanl.gov>
|
|
To: abc@banjo.concert.net
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: Alan B Clegg's message of Mon, 30 Mar 92 9:07:11 EST <9203301411.AA05105@p.lanl.gov>
|
|
Subject: RE: Ok, we have been envoked.
|
|
|
|
Ok, since the file system standard went over so well, I propose this
|
|
(open for discussion):
|
|
|
|
/dev/wd -- Western Digital and related disk controllers
|
|
/dev/wd0 -- entire disk 0
|
|
/dev/wd1 -- entire disk 1
|
|
/dev/wd01 -- disk 0, partition 1
|
|
--etc--
|
|
|
|
/dev/sd -- SCSI controllers
|
|
/dev/sd0 -- entire DEVICE 0
|
|
/dev/sd01 -- DEVICE 0, LUN 1
|
|
/dev/sd011 -- DEVICE 0, LUN 1, partition 1 [???]
|
|
|
|
Typically, the "sd" or "wd" refers to a controller type. The 0, 1, ... is a
|
|
logical unit, and a letter "a" .. "h" is used to specify the logical partition.
|
|
so we would have (using 8 partitions)
|
|
|
|
/dev/wd0a and /dev/sd0a
|
|
/dev/wd0b and /dev/sd0b
|
|
...
|
|
/dev/wd0h and /dev/sd0h
|
|
|
|
with one of the partitions mapping the entire disk. Sun currently uses "c" for
|
|
this.
|
|
|
|
/dev/tty[a-d] -- com1 -> com4 [???]
|
|
[from SunOS]
|
|
Or (more V7, BSDish) /dev/tty[0-4].
|
|
Also used were /dev/tty[0123][0123456789abcdef] for things like 16-line
|
|
multiplexors. The first [0123] specified a controller and the [0-f] specified
|
|
line 0-15 of the device.
|
|
|
|
Skip Egdorf
|
|
hwe@lanl.gov
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 30 13:27:35 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from JARTHUR.CLAREMONT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <14533-0@banjo.concert.net>; Mon, 30 Mar 1992 12:37:21 -0500
|
|
Date: Mon, 30 Mar 92 9:36:47 PST
|
|
From: "Jim Winstead Jr." <jwinstea@jarthur.Claremont.EDU>
|
|
To: Alan B Clegg <abc@banjo.concert.net>
|
|
cc: linux-standards@banjo.concert.net
|
|
Subject: Re: Ok, we have been envoked.
|
|
|
|
>Ok, since the file system standard went over so well, I propose this
|
|
>(open for discussion):
|
|
|
|
>/dev/wd -- Western Digital and related disk controllers
|
|
>/dev/wd0 -- entire disk 0
|
|
>/dev/wd1 -- entire disk 1
|
|
>/dev/wd01 -- disk 0, partition 1
|
|
|
|
Okay, what are 'Western Digitial and related controllers' as opposed
|
|
to anything else? Is this just 'standard' AT controllers? If so, I'd
|
|
recommened staying with /dev/hd*.
|
|
|
|
>/dev/tty -- "your" tty
|
|
>/dev/tty[a-d] -- com1 -> com4 [???]
|
|
|
|
I think it should be /dev/tty[0-3]. Most things should be kept
|
|
zero-based, I think, since it just makes things more consistent.
|
|
|
|
>/dev/ttyv[1-4] -- "virtual terminals" [???]
|
|
|
|
What would /dev/ttyv0 refer too? Another name for the current ttyv? Makes
|
|
sense to me.
|
|
|
|
>/dev/console -- /dev/ttyv1 [???]
|
|
>/dev/ttyp[0-f] -- pseudo terminals
|
|
>/dev/ttyq[0-f] pseudo terminals
|
|
|
|
These look reasonable, but leave room for expansion in the pseudo
|
|
terminals. (On my school computer, it runs from ttyp[0-9a-zA-z] and
|
|
stuff like that.)
|
|
|
|
>/dev/lp[ab] -- lpt1, lpt2
|
|
|
|
Again, I'd have to vote for /dev/lp[01]. Makes more sense to me.
|
|
--
|
|
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 linux-standards-request@banjo.concert.net Mon Mar 30 13:27:36 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from bernina.ethz.ch by banjo.concert.net with SMTP (PP)
|
|
id <14594-0@banjo.concert.net>; Mon, 30 Mar 1992 13:17:39 -0500
|
|
Received: from nessie by bernina.ethz.ch with SMTP inbound
|
|
id <17897-0@bernina.ethz.ch>; Mon, 30 Mar 1992 20:17:15 +0200
|
|
Received: by nessie.cs.id.ethz.ch; Mon, 30 Mar 92 20:17:09 +0200
|
|
Message-Id: <9203301817.AA25705@nessie.cs.id.ethz.ch>
|
|
From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
|
|
Date: Mon, 30 Mar 1992 20:17:08 +0000
|
|
In-Reply-To: Alan B Clegg <abc@banjo.concert.net> "Ok, we have been envoked." (Mar 30, 9:07)
|
|
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Re: Ok, we have been envoked.
|
|
|
|
> /dev/ttyv[1-4] -- "virtual terminals" [???]
|
|
> /dev/console -- /dev/ttyv1 [???]
|
|
|
|
I think, there should be a "current virtual console", maybe /dev/console
|
|
or /dev/ttyv ?
|
|
|
|
> /dev/ttyp[0-f] -- pseudo terminals
|
|
> /dev/ttyq[0-f] pseudo terminals
|
|
|
|
How about /dev/ttyp[0-9][0-9] and /dev/ttyq[0-9][0-9] ? Being limited to
|
|
16 ptys seems to be a bit odd in the days of iScreen and X.
|
|
|
|
- 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 linux-standards-request@banjo.concert.net Mon Mar 30 15:22:38 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP)
|
|
id <14712-0@banjo.concert.net>; Mon, 30 Mar 1992 13:33:38 -0500
|
|
Received: from ferrari.daimi.aau.dk by daimi.aau.dk
|
|
with SMTP (5.61++/IDA-1.2.8) id AA19609;
|
|
Mon, 30 Mar 92 20:33:27 +0200
|
|
Received: by ferrari.daimi.aau.dk (5.64/1.34) id AA19616;
|
|
Mon, 30 Mar 92 20:33:26 +0200
|
|
Date: Mon, 30 Mar 92 20:33:26 +0200
|
|
From: tthorn@daimi.aau.dk
|
|
Message-Id: <9203301833.AA19616@ferrari.daimi.aau.dk>
|
|
To: abc@banjo.concert.net, linux-standards@banjo.concert.net
|
|
In-Reply-To: Skip Egdorf's message of Mon, 30 Mar 92 08:43:58 MST <9203301543.AA00311@zaphod.lanl.gov.lanl.gov>
|
|
Subject: RE: Ok, we have been envoked.
|
|
|
|
Yes {wd,sd}[0-9][abcdefgh] seems right, but using c for the whole
|
|
disk is just a tad to strange for my liking. Would it be
|
|
to dangerous to just use {wd,sd}[0-9] ?
|
|
|
|
Also, I disagree with Ed Carp (erc@Apple.COM). As we are still
|
|
very early in development, it sure better to change a bad design,
|
|
than to stick with it, just for sake of existing software.
|
|
|
|
/Tommy
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 30 15:23:49 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <14733-0@banjo.concert.net>; Mon, 30 Mar 1992 13:36:02 -0500
|
|
Subject: Re: Ok, we have been envoked. (fwd)
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Mon, 30 Mar 92 13:35:58 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
|
|
> >/dev/wd -- Western Digital and related disk controllers
|
|
|
|
> Okay, what are 'Western Digitial and related controllers' as opposed
|
|
> to anything else? Is this just 'standard' AT controllers? If so, I'd
|
|
> recommened staying with /dev/hd*.
|
|
|
|
My machine has many more than just one type of 'hd', and like IBM getting away
|
|
with calling THEIR machine "THE PC", I don't like generic names like that.
|
|
|
|
SCSI hard disks are also 'hd' in that case... I have both IDE (wd type) and
|
|
SCSI (adaptec 1542) drives on my system, and I need a way to tell the
|
|
difference.
|
|
|
|
I like the idea of:
|
|
|
|
/dev/wd{controller}{partition}
|
|
/dev/sd{controller}{partition}
|
|
|
|
With controller being zero based, and using the berkeley lettering scheme
|
|
for the partitions:
|
|
|
|
a-h, c being the "WHOLE THING", b being swap, etc etc..
|
|
|
|
Also, I am not opposed to zero basing everything.
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 30 16:19:49 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from cinelli.Physics.McGill.CA by banjo.concert.net with SMTP (PP)
|
|
id <15307-0@banjo.concert.net>; Mon, 30 Mar 1992 16:19:26 -0500
|
|
Received: by cinelli.Physics.McGill.CA (5.57/Ultrix3.0-C) id AA09090;
|
|
Mon, 30 Mar 92 16:19:42 -0500
|
|
Date: Mon, 30 Mar 92 16:19:42 -0500
|
|
From: robbins@hep.physics.mcgill.ca (Steven Robbins)
|
|
Message-Id: <9203302119.AA09090@cinelli.Physics.McGill.CA>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: HD device names
|
|
|
|
|
|
Naming them /dev/wdxxx seems okay to me, but why on earth is wd0c the whole
|
|
disk? What's wrong with /dev/wd0 being all of disk zero, and /dev/wd0a being
|
|
the first partition, etc?
|
|
|
|
Now, how about floppies? Using /dev/at0 &etc is far too arcane for me, so
|
|
I've created /dev/a1200 /dev/a720 /dev/b1440 and stuff like that. I realize
|
|
of course that some people have different configurations, but if only the
|
|
drives that existed on the system were in /dev, then a program could figure
|
|
out what kind of floppies were around.
|
|
|
|
Actually, this reminds me of a question I had: in the directory standard,
|
|
I think it mentioned that the /dev directory should have ALL POSSIBLE devices,
|
|
and not just those that exist on the system. What's the rationale for this?
|
|
It would seem at first glance to be more advantageous the other way, so that
|
|
programs would know what kind of peripherals existed.
|
|
|
|
Steve Z
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 30 17:03:45 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <15534-0@banjo.concert.net>; Mon, 30 Mar 1992 17:03:20 -0500
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <10691-0@sun2.nsfnet-relay.ac.uk>; Mon, 30 Mar 1992 12:37:57 +0100
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa26852;
|
|
30 Mar 92 12:38 BST
|
|
Date: Mon, 30 Mar 92 12:38:16 +0100
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: linux-standards@banjo.concert.net
|
|
|
|
I am sending this article here since my site has problems with the news.
|
|
If abc think that this article is worth to be posted it will be nice
|
|
if he could poste it in the net.
|
|
|
|
Thanks to all
|
|
==================================
|
|
|
|
Hello !
|
|
|
|
This article will give you a simple way to have text and graphics
|
|
using a VGA graphic adapter.
|
|
|
|
Most of the ideas are taken from the mgr graphic interface for minix.
|
|
|
|
The idea behind this simple patch is described in the following file:
|
|
|
|
----------------------------------------------------------
|
|
|
|
|
|
|
|
VGAREGS(MS-DOS) Programmer's Manual (MS-DOS) VGAREGS(MS-DOS)
|
|
|
|
|
|
NAME
|
|
vgaregs - examine vga-adapter register values and generate an include
|
|
file for the MINIX/Linux screen driver.
|
|
|
|
SYNOPSIS
|
|
vgaregs [ax[_bx] ...] [ > video.h ]
|
|
|
|
DESCRIPTION
|
|
This program is intended to help you generating a proper include file for
|
|
the minix screen-driver if you are using a VGA display adapter.
|
|
|
|
It uses the BIOS video interrupt 0x10 to switch to each one of the modes
|
|
specified at the command line. Register AX is loaded by the 'ax' value,
|
|
and, if 'bx' is also specified, this is loaded into the BX register. AX
|
|
(and BX) must be given as hexadecimal numbers without a leading '0x'.
|
|
|
|
Vgaregs then reads the display adapter register values and tries to
|
|
determine the screen parameters. These parameters are printed on
|
|
standard output and should be redirected into a file.
|
|
|
|
|
|
OUTPUT FORMAT
|
|
Defines for the hercules-adapter in text and graphic modes are printed
|
|
first.
|
|
|
|
The next define is
|
|
#define REGBASE 0x3B4
|
|
if you have a monochrome monitor, and
|
|
#define REGBASE 0x3D4
|
|
if you have a color monitor connected to your VGA adapter.
|
|
|
|
For each video mode then definitions are printed in the form
|
|
|
|
#define MODE_XX \
|
|
`register values'
|
|
|
|
and
|
|
|
|
#define PARM_XX \
|
|
PP( `video mode parameters' )
|
|
|
|
where `register values' is a list of the register values read from the
|
|
adapter (in the correct order as required by the screen driver), and
|
|
`screen parameters' is a guess of the screen parameters. The latter list
|
|
is not always correct, so you should compare this to your documentation.
|
|
'XX' will be replaced by the corresponding command line string. (The
|
|
macro PP() is a hack for the C-preprocessor).
|
|
|
|
The 'screen parameter' entries are in the following order:
|
|
|
|
Physical Start address of video memory (short int)
|
|
Size of video memory in bytes (long int)
|
|
Pixels per line (short int)
|
|
Pixels per row (short int)
|
|
Number of bitplanes (short int)
|
|
always assumed to be 4 (16-color modes)
|
|
Interlace Flag (short int)
|
|
always set to 0
|
|
Number of interlaced Pages (short int)
|
|
always set to 1
|
|
Pagesize of interlaced pages (short int)
|
|
always set to 0
|
|
|
|
The first text mode and the first three graphic video modes given at the
|
|
command line should be those you actually want to use in the MINIX screen
|
|
driver. For these modes defines are added with names ?VGA_GRAF_PARMS,
|
|
?VGA_GRAF_MODE, VGA_TEXT_PARMS and VGA_TEXT_MODE, for all other modes a
|
|
comment like /* This mode is not used */.
|
|
|
|
EXAMPLE
|
|
vgaregs 3 10 12 29 37 > video.h
|
|
will generate an include file named video.h with definitions for textmode
|
|
(mode 3), 640x350 16 colors (mode 0x10), 640x480 16 colors (mode 0x12),
|
|
800x600 16 colors (mode 0x29) and 1024x768 16 colors (mode 0x37) for the
|
|
'OPTIMA/1024 plus' display adapter (TSENG 3000 chip). The names MODE_3,
|
|
MODE_10, MODE_12, MODE_29 and MODE_37 in the output file hold the
|
|
register values, PARM_3, PARM_10, PARM_12, PARM_29 and PARM_37 hold the
|
|
screen parameters. The values for PARM_37 are not determined correctly
|
|
by this program (See section BUGS). The generated include file will use
|
|
BIOS mode 3 as textmode, and modes 10, 12 and 29 as graphic modes.
|
|
|
|
FURTHER HINTS
|
|
You can use vgaregs to collect information about ALL videomodes your
|
|
adapter can handle into one file. Only the first textmode encountered
|
|
and the first three graphic modes encountered are then used by the MINIX
|
|
screen driver.
|
|
You can then play with all these modes by simply changing some defines in
|
|
the generated file.
|
|
|
|
Vgaregs uses the registers as the BIOS will set them. So it will
|
|
generate the same cursor shape (underline) as MS-DOS uses it by default.
|
|
If you like the MINIX block-type cursor, patch the MODE definition in the
|
|
output file for TEXT mode (entries 11 and 12 should be set to 0x00 and
|
|
0x0F resp.).
|
|
Also worth patching are the color attribute registers (entries 25 - 40 in
|
|
the MODE definition), if you don't like the default colors.
|
|
|
|
BUGS
|
|
Vgaregs is an MS-DOS program, as it uses the VGA-BIOS.
|
|
Vgaregs does not determine if you actually have a VGA adapter.
|
|
Vgaregs only knows about standard VGA registers, so probably 1024x768
|
|
modes will never work (although modes up to 800x600 resolution usually
|
|
do).
|
|
Vgaregs (and also the screen driver) only works for VGA-modes with 16
|
|
colors or less.
|
|
Vgaregs is ugly code.
|
|
|
|
-------------------------------------------------------------------------
|
|
The above file describes the operations of the MSDOS vgaregs.exe program.
|
|
The all purpose of the program is to generate the vga.h file !
|
|
|
|
After that you can use it to create the new kernel using the following files.
|
|
The following one is the actual ioctl switch command...
|
|
|
|
---------------------------------------------------------------------
|
|
|
|
/* Ident: fs/vga_ioctl.c
|
|
* Author : Damiano Bolla
|
|
* This implement the vga switching..... what a pain
|
|
* Based of the minix mgr manager
|
|
*/
|
|
|
|
#include <asm/io.h>
|
|
#include <asm/system.h>
|
|
#include <asm/memory.h>
|
|
#include <errno.h>
|
|
#include <linux/fs.h>
|
|
#include <linux/kernel.h>
|
|
#include <linux/videodef.h> /* Definition of video modes */
|
|
#include <linux/screen.h> /* Structures used by the sys */
|
|
|
|
/* the next one is used to tell to the rest of the system where the
|
|
* Current vido map is and how long it is.
|
|
* NOTE: It is apointer to something ! ( when is set )
|
|
*/
|
|
|
|
struct scr_param *VideoParam = NULL;
|
|
|
|
/* Some additional structure to keep the informations for switching */
|
|
struct scr_defs
|
|
{
|
|
struct scr_param params;
|
|
char regs[60];
|
|
};
|
|
|
|
/*
|
|
* Hack for the preprocessor (the most abused tool in the world?).
|
|
* Video parameters are defined as PP( .... ) in videodef.h
|
|
*/
|
|
#define PP(x1,x2,x3,x4,x5,x6,x7,x8) \
|
|
x1, x2, x3, x4, x5, x6, x7, x8
|
|
|
|
|
|
static struct scr_defs
|
|
Vga_Text = { { VGA_TEXT_PARMS }, { VGA_TEXT_MODE } },
|
|
Vga_Graf = { { VGA_GRAF_PARMS }, { VGA_GRAF_MODE } },
|
|
/* If you have the right values put them in in here..... */
|
|
Svga_Graf = { { VGA_GRAF_PARMS }, { VGA_GRAF_MODE } },
|
|
Evga_Graf = { { VGA_GRAF_PARMS }, { VGA_GRAF_MODE } };
|
|
|
|
extern int vga_mode( int mode );
|
|
|
|
int vga_ioctl(int dev, int cmd, int arg)
|
|
{
|
|
switch( cmd )
|
|
{
|
|
case SCRSETMODE:
|
|
/* arg defines the requested vga status we want */
|
|
vga_mode ( arg );
|
|
return (0);
|
|
break;
|
|
case SCRGETP:
|
|
return (0);
|
|
break;
|
|
}
|
|
return EINVAL;
|
|
}
|
|
|
|
|
|
/* ================= VGA index register ports: ======================= */
|
|
#define CRT_I 0x3D4 /* CRT Controller Index (0x3D4=color, 0x3B4=mono) */
|
|
#define ATT_IW 0x3C0 /* Attribute Controller Index & Data Write Reg. */
|
|
#define GRA_I 0x3CE /* Graphics Controller Index */
|
|
#define SEQ_I 0x3C4 /* Sequencer Index */
|
|
|
|
/* VGA data register ports: */
|
|
#define CRT_D 0x3D5 /* CRT Contr. Data Reg. (0x3D5=color, 0x3B5=mono) */
|
|
#define ATT_R 0x3C1 /* Attribute Controller Data Read Register */
|
|
#define GRA_D 0x3CF /* Graphics Controller Data Register */
|
|
#define SEQ_D 0x3C5 /* Sequencer Data Register */
|
|
#define MIS_R 0x3CC /* Misc Output Read Register */
|
|
#define MIS_W 0x3C2 /* Misc Output Write Register */
|
|
#define IS1_R 0x3DA /* Input Status Register 1 (Read only)
|
|
(0x3DA=color, 0x3BA=mono) */
|
|
/* VGA indexes max counts: */
|
|
#define CRT_C 24 /* 24 -CRT Controller Registers*/
|
|
#define ATT_C 21 /* 21 -Attribute Controller Registers */
|
|
#define GRA_C 9 /* 9 -Graphics Controller Registers */
|
|
#define SEQ_C 5 /* 5 -Sequencer Registers */
|
|
#define MIS_C 1 /* 1 -Misc Output Register */
|
|
|
|
/* VGA registers saving indexes */
|
|
#define CRT 0 /* CRT Controller Registers start */
|
|
#define ATT CRT+CRT_C /* Attribute Controller Registers start */
|
|
#define GRA ATT+ATT_C /* Graphics Controller Registers -"- */
|
|
#define SEQ GRA+GRA_C /* Sequencer Registers */
|
|
#define MIS SEQ+SEQ_C /* General Registers */
|
|
#define END MIS+MIS_C /* last */
|
|
|
|
|
|
int vga_mode( int mode )
|
|
{
|
|
static int curr_mode = VGA_TEXT; /* We know this is the initial */
|
|
char *regs; /* pointer to new register values */
|
|
int i;
|
|
|
|
#ifndef ROM_CHAR_SET
|
|
static char vga_char_map[8192]; /* character map buffer */
|
|
static map_initialized = 0; /* The map is not initalized */
|
|
#endif
|
|
|
|
/* Let'see if we need to switch..... */
|
|
if ( curr_mode == mode ) return (0);
|
|
|
|
switch(mode)
|
|
{
|
|
case VGA_TEXT:
|
|
regs = Vga_Text.regs;
|
|
VideoParam = &Vga_Text.params;
|
|
break;
|
|
case VGA_640x480:
|
|
regs = Vga_Graf.regs;
|
|
VideoParam = &Vga_Graf.params;
|
|
break;
|
|
case VGA_600x800:
|
|
regs = Svga_Graf.regs;
|
|
VideoParam = &Svga_Graf.params;
|
|
break;
|
|
case VGA_1024x768:
|
|
regs = Evga_Graf.regs;
|
|
VideoParam = &Evga_Graf.params;
|
|
break;
|
|
default:
|
|
return EINVAL;
|
|
break;
|
|
}
|
|
|
|
/* Do we want to switch to text mode ??.. if so we need to restore */
|
|
if ( (mode == VGA_TEXT) && (map_initialized == 1) )
|
|
{
|
|
/* restore character map before setting TEXT mode */
|
|
outb(0x04, GRA_I );
|
|
outb(0x02, GRA_D ); /* select page 2 where to write map */
|
|
|
|
#ifndef ROM_CHAR_SET
|
|
(void) memcpy ((char *)0xA0000L, vga_char_map, sizeof (vga_char_map));
|
|
#else
|
|
{
|
|
int i;
|
|
for (i=0; i<256; i++)
|
|
(void) memcpy ( (char *)(0xA0000L+(i+32)), (char *)(ROM_CHAR_SET+(i*16)), 16 );
|
|
}
|
|
#endif
|
|
}
|
|
|
|
/* ------------- set VGA registers to new values ---------------------*/
|
|
inb(IS1_R); /* clear flip-flop */
|
|
outb(0x00, ATT_IW ); /* Disable video */
|
|
|
|
outb(GRA_I,0x00);
|
|
outb(GRA_D,0x00); /* Set/Reset (graph) */
|
|
|
|
inb(IS1_R); /* clear flip-flop */
|
|
outb(SEQ_I,0x00);
|
|
outb(SEQ_D,0x01); /* synchronous reset ON */
|
|
|
|
/*
|
|
* IMPORTANT NOTE: (speaking from experience!)
|
|
* BE SURE *** NOT *** TO ACCESS THE VIDEO MEMORY WHILE THE SEQUENCER IS OFF !!!
|
|
* THE CPU WILL WAIT FOREVER ON THE SCREEN ACCESS...
|
|
*/
|
|
outb(regs[MIS+0], MIS_W ); /* update misc output reg */
|
|
|
|
outb(0x1, SEQ_I );
|
|
outb(regs[SEQ+1], SEQ_D ); /* update clocking mode */
|
|
|
|
for (i=2;i<SEQ_C;i++) /* Sequencer Registers */
|
|
{
|
|
outb(i, SEQ_I);
|
|
outb(regs[SEQ+i], SEQ_D);
|
|
}
|
|
|
|
/* ---------------- deprotect registers 0-7 ----------------------- */
|
|
outb(0x11, CRT_I ); /* Vertical retrace end reg */
|
|
outb(regs[CRT+0x11]&0x7F, CRT_D); /* enable write to reg 0-7 */
|
|
|
|
for (i=0;i<CRT_C;i++) /* CRT Controller Registers */
|
|
{
|
|
outb(i, CRT_I);
|
|
outb(regs[CRT+i], CRT_D);
|
|
}
|
|
|
|
for (i=0;i<GRA_C;i++) /* Graphics Controller Registers */
|
|
{
|
|
outb(i, GRA_I);
|
|
outb(regs[GRA+i], GRA_D);
|
|
}
|
|
|
|
#ifdef NO_ATTRIBUTES_ARE_RESTORED
|
|
outb(0x10, ATT_IW); /* Attribute Mode Control Reg */
|
|
outb(regs[ATT+0x10] ATT_IW);
|
|
outb(0x13, ATT_IW ); /* Horizontal PEL Panning Reg (Attr) */
|
|
outb(regs[ATT+0x13], ATT_IW);
|
|
#else
|
|
for (i=0;i<ATT_C;i++) /* Attribute Controller Reg */
|
|
{
|
|
inb(IS1_R); /* Reset Flipflop */
|
|
outb(i, ATT_IW);
|
|
outb(regs[ATT+i],ATT_IW);
|
|
}
|
|
#endif
|
|
|
|
outb(0x00, SEQ_I);
|
|
outb(0x03, SEQ_D); /* synchronous reset OFF */
|
|
|
|
/* ----------------- now video accesses are possible again --------- */
|
|
|
|
inb(IS1_R);
|
|
outb(0x20, ATT_IW); /* Enable video */
|
|
|
|
#ifndef ROM_CHAR_SET
|
|
/* If the buffer for the array map is not recorded we record it */
|
|
/* The map is one the screen page number 2... */
|
|
if ( map_initialized == 0 )
|
|
{
|
|
map_initialized = 1;
|
|
outb(0x04, GRA_I);
|
|
outb(0x02, GRA_D); /* select page 2 to get thw map */
|
|
(void) memcpy ( vga_char_map, (char *)(0xA0000L), sizeof(vga_char_map) );
|
|
outb(0x04, GRA_I);
|
|
outb(regs[GRA+0x04], GRA_D); /* restore map mask */
|
|
}
|
|
#endif
|
|
|
|
curr_mode = mode; /* keep track of video mode for next call */
|
|
return 0;
|
|
}
|
|
|
|
|
|
--------------------------------------------------------------------------
|
|
|
|
This one is the modified char_dev.c to support a write to the newly
|
|
created device. I am using the device 1 0 since this all thing is a test.
|
|
NOTE that the all thing is reasonably safe since the write to the device
|
|
checks the boundaries.
|
|
|
|
To create the new device do:
|
|
mknod /dev/vga c 1 0
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
/*
|
|
* linux/fs/char_dev.c
|
|
*
|
|
* (C) 1991 Linus Torvalds
|
|
*/
|
|
|
|
#include <errno.h>
|
|
#include <sys/types.h>
|
|
|
|
#include <linux/sched.h>
|
|
#include <linux/kernel.h>
|
|
|
|
#include <asm/segment.h>
|
|
#include <asm/io.h>
|
|
|
|
#include <linux/screen.h> /* To read write to screen */
|
|
|
|
extern int tty_read(unsigned minor,char * buf,int count,unsigned short flags);
|
|
extern int tty_write(unsigned minor,char * buf,int count);
|
|
extern int lp_write(unsigned minor,char *buf, int count);
|
|
|
|
typedef (*crw_ptr)(int,unsigned,char *,int,off_t *,unsigned short);
|
|
|
|
static int rw_ttyx(int rw,unsigned minor,char * buf,int count,off_t * pos, unsigned short flags)
|
|
{
|
|
return ((rw==READ)?tty_read(minor,buf,count,flags):
|
|
tty_write(minor,buf,count));
|
|
}
|
|
|
|
|
|
static int rw_lp(int rw,unsigned minor,char * buf,int count,off_t * pos)
|
|
{
|
|
return ((rw==READ)? -EINVAL:
|
|
lp_write(minor,buf,count));
|
|
}
|
|
|
|
static int rw_tty(int rw,unsigned minor,char * buf,int count, off_t * pos, unsigned short flags)
|
|
{
|
|
if (current->tty<0)
|
|
return -EPERM;
|
|
return rw_ttyx(rw,current->tty,buf,count,pos,flags);
|
|
}
|
|
|
|
extern struct scr_param *VideoParam;
|
|
|
|
static int rw_ram(int rw,char * buf, int count, off_t *pos)
|
|
{
|
|
/* This is supposed to access the VGA video ram..... */
|
|
int i = *pos;
|
|
int base, limit;
|
|
|
|
/* If we have an invalid pointer to the data we can't go on */
|
|
if ( VideoParam == NULL ) return (-EIO);
|
|
|
|
base = VideoParam->scr_base;
|
|
limit = base + VideoParam->scr_fbsize;
|
|
i+= base;
|
|
|
|
while ( (count-- > 0) && (i <limit )) {
|
|
if (rw==READ)
|
|
put_fs_byte( *(char *)i ,buf++);
|
|
else
|
|
*(char *)i = get_fs_byte ( buf++ );
|
|
i++;
|
|
}
|
|
i -= base; /* Take avay the base... */
|
|
i -= *pos; /* Count how many read or write */
|
|
*pos += i; /* Update position */
|
|
return (i); /* Return number read */
|
|
}
|
|
|
|
static int rw_mem(int rw,char * buf, int count, off_t * pos)
|
|
{
|
|
return -EIO;
|
|
}
|
|
|
|
static int rw_kmem(int rw,char * buf, int count, off_t * pos)
|
|
{
|
|
/* kmem by Damiano */
|
|
int i = *pos; /* Current position where to read */
|
|
|
|
/* i can go from 0 to LOW_MEM (See include/linux/mm.h */
|
|
/* I am not shure about it but it doesn't mem fault :-) */
|
|
while ( (count-- > 0) && (i <LOW_MEM) ) {
|
|
if (rw==READ)
|
|
put_fs_byte( *(char *)i ,buf++);
|
|
else
|
|
*(char *)i = get_fs_byte ( buf++ );
|
|
i++;
|
|
}
|
|
i -= *pos; /* Count how many read or write */
|
|
*pos += i; /* Update position */
|
|
return (i); /* Return number read */
|
|
}
|
|
|
|
static int rw_port(int rw,char * buf, int count, off_t * pos)
|
|
{
|
|
int i=*pos;
|
|
|
|
while (count-->0 && i<65536) {
|
|
if (rw==READ)
|
|
put_fs_byte(inb(i),buf++);
|
|
else
|
|
outb(get_fs_byte(buf++),i);
|
|
i++;
|
|
}
|
|
i -= *pos;
|
|
*pos += i;
|
|
return i;
|
|
}
|
|
|
|
static int rw_memory(int rw, unsigned minor, char * buf, int count,
|
|
off_t * pos, unsigned short flags)
|
|
{
|
|
switch(minor) {
|
|
case 0:
|
|
return rw_ram(rw,buf,count,pos);
|
|
case 1:
|
|
return rw_mem(rw,buf,count,pos);
|
|
case 2:
|
|
return rw_kmem(rw,buf,count,pos);
|
|
case 3:
|
|
return (rw==READ)?0:count; /* rw_null */
|
|
case 4:
|
|
return rw_port(rw,buf,count,pos);
|
|
default:
|
|
return -EIO;
|
|
}
|
|
}
|
|
|
|
#define NRDEVS ((sizeof (crw_table))/(sizeof (crw_ptr)))
|
|
|
|
static crw_ptr crw_table[]={
|
|
NULL, /* nodev */
|
|
rw_memory, /* /dev/mem etc */
|
|
NULL, /* /dev/fd */
|
|
NULL, /* /dev/hd */
|
|
rw_ttyx, /* /dev/ttyx */
|
|
rw_tty, /* /dev/tty */
|
|
rw_lp, /* /dev/lp */
|
|
NULL}; /* unnamed pipes */
|
|
|
|
int char_read(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(READ,minor,buf,count,&filp->f_pos,filp->f_flags);
|
|
}
|
|
|
|
int char_write(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(WRITE,minor,buf,count,&filp->f_pos,filp->f_flags);
|
|
}
|
|
|
|
-------------------------------------------------------------------------
|
|
Of course to have the ioctl to work in the major 1 we need to
|
|
change the ioctl.c too :-)
|
|
|
|
----------------------------------------------------------------------
|
|
|
|
/*
|
|
* linux/fs/ioctl.c
|
|
*
|
|
* (C) 1991 Linus Torvalds
|
|
*/
|
|
|
|
#include <string.h>
|
|
#include <errno.h>
|
|
#include <sys/stat.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
extern int tty_ioctl(int dev, int cmd, int arg);
|
|
extern int pipe_ioctl(struct inode *pino, int cmd, int arg);
|
|
extern int vga_ioctl(int dev, int cmd, int arg);
|
|
|
|
typedef int (*ioctl_ptr)(int dev,int cmd,int arg);
|
|
|
|
#define NRDEVS ((sizeof (ioctl_table))/(sizeof (ioctl_ptr)))
|
|
|
|
static ioctl_ptr ioctl_table[]={
|
|
NULL, /* nodev */
|
|
vga_ioctl, /* /dev/mem (VGA temporarly ) */
|
|
NULL, /* /dev/fd */
|
|
NULL, /* /dev/hd */
|
|
tty_ioctl, /* /dev/ttyx */
|
|
tty_ioctl, /* /dev/tty */
|
|
NULL, /* /dev/lp */
|
|
NULL}; /* named pipes */
|
|
|
|
|
|
int sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
|
|
{
|
|
struct file * filp;
|
|
int dev,mode;
|
|
|
|
if (fd >= NR_OPEN || !(filp = current->filp[fd]))
|
|
return -EBADF;
|
|
if (filp->f_inode->i_pipe)
|
|
return (filp->f_mode&1)?pipe_ioctl(filp->f_inode,cmd,arg):-EBADF;
|
|
mode=filp->f_inode->i_mode;
|
|
if (!S_ISCHR(mode) && !S_ISBLK(mode))
|
|
return -EINVAL;
|
|
dev = filp->f_inode->i_rdev;
|
|
if (MAJOR(dev) >= NRDEVS)
|
|
return -ENODEV;
|
|
if (!ioctl_table[MAJOR(dev)])
|
|
return -ENOTTY;
|
|
return ioctl_table[MAJOR(dev)](dev,cmd,arg);
|
|
}
|
|
|
|
-------------------------------------------------------------------------
|
|
It is not finish... we need the include files now.
|
|
-------------------------------------------------------------------------
|
|
|
|
|
|
/* Data structures for IOCTL on /dev/screen */
|
|
/* This goes in /usr/src/linux/include/linux/screen.h */
|
|
|
|
#ifndef _SCREEN_H
|
|
#define _SCREEN_H
|
|
|
|
/*
|
|
* physical screen attributes; information returned by the
|
|
* SCRGETP ioctl call
|
|
*/
|
|
struct scr_param {
|
|
unsigned long scr_base; /* physical address of screen */
|
|
unsigned int scr_fbsize; /* size of framebuffer */
|
|
/* the following fields only have meaning in graphic modes. */
|
|
unsigned short scr_width; /* width of screen (pixels) */
|
|
unsigned short scr_height; /* height of screen (pixels) */
|
|
unsigned short scr_depth; /* no. of bitplanes on screen */
|
|
short scr_interlace; /* 1 if interlaced, 0 if not */
|
|
/* the following fields on;y have meaning if interlaced */
|
|
unsigned short scr_numpages; /* number of interlaced pages */
|
|
unsigned short scr_pagesize; /* address distance between the
|
|
* first pixel in the first line
|
|
* and the first pixel in the
|
|
* second line
|
|
*/
|
|
};
|
|
|
|
/* ioctl(2) - commands that you can use with this stuff */
|
|
|
|
#define SCRGETP 1 /* return scr_parameters */
|
|
#define SCRSETMODE 2 /* switch video mode (text/graphic) */
|
|
|
|
/* Possible vga configurations that you can have */
|
|
|
|
#define VGA_TEXT 3 /* text mode */
|
|
#define VGA_640x480 4 /* graphics mode */
|
|
#define VGA_600x800 5 /* graphics mode */
|
|
#define VGA_1024x768 6 /* graphics mode */
|
|
|
|
|
|
#endif /* _SCREEN_H */
|
|
|
|
-------------------------------------------------------------------------
|
|
|
|
/*
|
|
* include/linux/videodef.h
|
|
*
|
|
* The values for EGA/VGA adapters (depending on which adapter you
|
|
* have, and which modes you want to use) are #included below by the file
|
|
* 'vga.h'.
|
|
*/
|
|
|
|
/*
|
|
* struct scr_defs contains:
|
|
* 1. (in struct scr_param) the physical screen parameters, as defined
|
|
* in <screen.h>.
|
|
* This information, like number of pixels at the display ... are
|
|
* made available to user programs by the kernel (via ioctl()-call).
|
|
*
|
|
* 2. (in regs[]) the register values which should be written into the
|
|
* hardware registers when switching to this video mode.
|
|
* This information is only needed by the kernel itself.
|
|
*/
|
|
|
|
|
|
/*
|
|
* Definitions for EGA/VGA adapters.
|
|
*/
|
|
#include "vga.h"
|
|
|
|
/* If you know where the address of your rom character map is
|
|
* you can save 8k in the kernel :-)
|
|
* #define ROM_CHAR_SET 0xC4F64L
|
|
*/
|
|
|
|
------------------------------------------------------------------------
|
|
The next one is the vga.h file generated by my vgaregs.exe using
|
|
vgaregs.exe 3 12 >vga.h from DOS.
|
|
You should generate you own and use that !
|
|
This is included just to show how things are
|
|
---------------------------------------------------------------------------
|
|
|
|
#define HERC_TEXT_MODE \
|
|
0x20,0x61,0x50,0x52,0x0f,0x19,0x06,0x19,0x19,0x02,0x0d,0x00,0x0d
|
|
|
|
#define HERC_TEXT_PARMS \
|
|
0xB0000L, 4000, 0, 0, 1, 0, 1, 0
|
|
|
|
#define HERC_GRAF_MODE \
|
|
0x02,0x35,0x2d,0x2e,0x07,0x5b,0x02,0x57,0x57,0x02,0x03,0x00,0x00
|
|
|
|
#define HERC_GRAF_PARMS \
|
|
0xB0000L, 32768, 720, 348, 1, 1, 4, 0x2000
|
|
|
|
#define REGBASE = 0x3D4
|
|
|
|
#define MODE_3 \
|
|
0x5F,0x4F,0x50,0x82,0x55,0x81,0xBF,0x1F,0x00,0x4F,0x0D,0x0E, \
|
|
0x00,0x00,0x00,0x00,0x9C,0x8E,0x8F,0x28,0x1F,0x96,0xB9,0xA3, \
|
|
0x00,0x01,0x02,0x03,0x04,0x05,0x14,0x07,0x38,0x39,0x3A,0x3B, \
|
|
0x3C,0x3D,0x3E,0x3F,0x0C,0x00,0x0F,0x08,0x00, \
|
|
0x00,0x00,0x00,0x00,0x00,0x10,0x0E,0x00,0xFF, \
|
|
0x03,0x00,0x03,0x00,0x02, \
|
|
0x67
|
|
|
|
/* PP( ) is a hack for cpp */
|
|
|
|
#define PARMS_3 \
|
|
PP( 0xB8000L, 4000L, 0, 0, 4, 0, 1, 0 )
|
|
#define VGA_TEXT_MODE MODE_3
|
|
#define VGA_TEXT_PARMS PARMS_3
|
|
|
|
#define MODE_12 \
|
|
0x5F,0x4F,0x50,0x82,0x54,0x80,0x0B,0x3E,0x00,0x40,0x00,0x00, \
|
|
0x00,0x00,0x00,0x00,0xEA,0x8C,0xDF,0x28,0x00,0xE7,0x04,0xE3, \
|
|
0x00,0x01,0x02,0x03,0x04,0x05,0x14,0x07,0x38,0x39,0x3A,0x3B, \
|
|
0x3C,0x3D,0x3E,0x3F,0x01,0x00,0x0F,0x00,0x00, \
|
|
0x00,0x00,0x00,0x00,0x00,0x00,0x05,0x0F,0xFF, \
|
|
0x03,0x01,0x0F,0x00,0x06, \
|
|
0xE3
|
|
|
|
/* PP( ) is a hack for cpp */
|
|
|
|
#define PARMS_12 \
|
|
PP( 0xA0000L, 38400, 640, 480, 4, 0, 1, 0 )
|
|
#define VGA_GRAF_MODE MODE_12
|
|
#define VGA_GRAF_PARMS PARMS_12
|
|
|
|
--------------------------------------------------------------------
|
|
Ok. Before putting the actual vgaregs.exe in uuencode format.. few points.
|
|
1) I have a MONO monitor. and a unknown chipsed VGA
|
|
2) To use the thing my system MUST start in the default 80x25 and COLOR mode
|
|
If I start in a different screen mode then I have trouble!
|
|
3) What this gives you is a working example of switching.
|
|
NO graphics primitives areimplemented :-)
|
|
If you want to play just write something to
|
|
/dev/vga and see what happens.
|
|
4) When you are in graphics mode there is NO WAY to see messages from
|
|
the kernel or printf...
|
|
Here it is my SIMPLE program to test the thing.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
#include <stdio.h>
|
|
#include <sys/types.h>
|
|
#include <unistd.h>
|
|
#include <fcntl.h>
|
|
#include <linux/screen.h>
|
|
|
|
|
|
main ()
|
|
{
|
|
int fd;
|
|
int i;
|
|
char val='a' ;
|
|
|
|
if ( (fd=open("/dev/vga", O_RDWR) ) < 0 )
|
|
{
|
|
printf ("cant open vga \n");
|
|
exit (1);
|
|
}
|
|
|
|
ioctl ( fd, SCRSETMODE, VGA_640x480 );
|
|
|
|
for (i=0; i<65000; i++ )
|
|
if ( write (fd, &val, 1) < 1 )
|
|
{
|
|
ioctl ( fd, SCRSETMODE, VGA_TEXT );
|
|
printf ("i is %d ",i);
|
|
break;
|
|
}
|
|
|
|
sleep (2);
|
|
ioctl ( fd, SCRSETMODE, VGA_TEXT );
|
|
|
|
lseek (fd, 0, SEEK_SET );
|
|
|
|
for (i=0; i<4000; i++ )
|
|
write (fd, &val, 1);
|
|
|
|
sleep (2);
|
|
ioctl ( fd, SCRSETMODE, VGA_640x480 );
|
|
|
|
sleep (2);
|
|
ioctl ( fd, SCRSETMODE, VGA_TEXT );
|
|
lseek (fd, 0, SEEK_SET );
|
|
|
|
val = 0;
|
|
for (i=0; i<4000; i++ )
|
|
if ( write (fd, &val, 1) < 1 )
|
|
{
|
|
ioctl ( fd, SCRSETMODE, VGA_TEXT );
|
|
printf ("i text is %d ",i);
|
|
break;
|
|
}
|
|
|
|
close (fd);
|
|
}
|
|
|
|
-----------------------------------------------------------------
|
|
The next program is the DOS program to catch the vag registes
|
|
------------------------------------------------------------------
|
|
|
|
begin 644 vgaregs.exe.Z
|
|
M'YV03;2$`Z`!``$`(`"8`_#O'YT!`!#X"<;N(``/`#(&`$"D@!X!]RP&*I`1
|
|
MFT<!&5.J7,FRI<N7,&/*G$FSILV;.'/JW,FSI\^?0(,*'4H49Y5%[`:Q4W#%
|
|
M"BXA`*"@&Z5@$#$!QHSP`[#(AK4&BK2J(+<(WR)K[A8)`[((WEEVB(SX&PL%
|
|
M5Y&HZ/)4)49@T;$>&^E$Z'$``!T8/208'M+C@F$EZQ"$G4MNE+<'@/SP6U!'
|
|
M`:XF>)/L%>!/:V9^&.;46/<)DCVY`N@4`&2@6H,`K_T!H3.-MFT!ZYA-'IO`
|
|
M`+4&ZX)!&DZNQ,%1VI#/@H1K"MX`H[-N#?6U@`&N;JVQ"\MOK"Y@`]SI"C:`
|
|
M7=TL>+4EL$K@-&?/8?`JFW^U-+_3%<A!#'<->`=`(D:8!0T[N"1T7GJXG($7
|
|
M*?QAI157=MA#WEAEZ>),>KH\TUY<_M35!EZ`\-?77]_1H8-]G>%2!UYI5.C?
|
|
M:0G(,0PN>^!E187:`;`A.;H0DYX.Q-1!!BX0K5/&<G)Q"$\)&XV"30.+&%,"
|
|
M`X9)T,-!=(30`P*&J=`#EW3,L$XHD!QC`#<-``"*F]`L``@`;DJS0$;K,.(F
|
|
MG'+2N0`0`*RCSI]QPB)H0NMP@R@`N*P#CR[%M$<7+H'@!0T"],'H62)X`<-I
|
|
M?Z9I5L`<`Z0CQC^X/(*7*J,*H`LSEI)35R5X93(J`5Y\L4@Y7>S8252X0&&`
|
|
M5$?LBDL(`=1EK%0Y*/N!`,X>B\X*RD9";;'6=J#L1E+%,X!5`@P#R5%)L<-!
|
|
M4\<8`4]&[;*3T2!^$!!`'0.@$PJKPE"+C@JQXL*-OR`$',(`4ED0,`\(H\-`
|
|
MP&$T+$#`>S2,SP'DXH*>5.Y@?!4NVS1,CL<"[$*H(\/L,@8`)BQRP"A?U:4`
|
|
M`5(MXW%??JBSB!T&K!,%+J`\D(D4=4%",SJS>&P`+I@<G0K)N'QR]"<DAW+E
|
|
M`L`(1B\\`OR1JA4!_$,#+A(4L,X#D-`K+[[IG!#VV*X<+<?-_SA!`-M?!-"(
|
|
M$?1`L;<\=3D'Q2#&""`V.L&(8!4"@`'`!S=_^VT$X+A`@!<+BA-C@-BXK'`T
|
|
M##>O`(QE#XQR'($&EK7(->R(_J`[Z'S!#^K?J<YZ@P"\CHL/1^-C`+F<>W$T
|
|
M.[_S%0J<*T@3"P'1@!.--/XD4P<^1.,RQ]'1%/^[#U<"P#8!_X1R7"8%;#2(
|
|
M-``0'<IEY)N//M'HC","@N8D8H6^=2YB@9ZQ*-#\\]&;WB*<8(Y%>`$=.]"&
|
|
M'!1P!P+L`!EVZ(LV%H&,*?PL$$>K@_;$UP`@0&%]#XC%`*8!C@*0J2Z'.-H6
|
|
MM)>.5_@#$IQ[QM&64#SPC>T=1_M!#?]A!':DXQC^,"`\%'$(/!0`$P@BA]CJ
|
|
M,H,"2"4$VA/;/^Q`#EQ0P8GHD$`4W94.3;PP$3P+A`^^0HT!U.$`[9)'DPJ0
|
|
MQL)$+G*5PXLT0&`5`XBN5[\*%B1H`8-FA(`'`IB#`)H!@E_800!=0<D*[A$(
|
|
M?P```G(8@"\>J0]'7",0Q+C,/N8``0M\`!WW",`,@"&5".+B'TSPXR#(X0\;
|
|
M),($@BB`*TW@AP)D:7DD1((-1L&'`@S@'HFP`4H8,8P5>.,>VZ"%$OQH`T9X
|
|
M8!X%L,`!^/$+020@%^!XP`J>,<IYJ,*3"`0`."61KP`(8`;M^(<-*+`Y&VA1
|
|
MG1`P`#KTP0^IB`-2AW0$-I@$`!NX"1`%$(.U]A``=/1C`*>,RC\L`%`^^G$4
|
|
M]2@`+@!0`S\FP@/A*``C##".`CC@`Q,M@2X`ZD=/+L(!G$#`.%S@"`-`LV4V
|
|
M8`$`BF$`3R"`$=J8P39L\`\/:`(!<XCF!]+1A`#8@*:BN*DV=@$1GOH4`9YL
|
|
MZ4M/*M-QV,`1P9C!/TP`B!X8A@6YX)(OJ%&`>9B"#@O(Q3_^,$IYN*(.&5A'
|
|
M.0S@@0-\8!'W^`4_"L`*3$2"%?[(6@"0H`IQW,.3NS@(($ZQUU],E`A^7*`]
|
|
MA`$(V0#B$7L%PA+R<`Y?F`(!O_@L.D0!`,^"5K2*`,`PT.4+9"3@%ZY%1Q]*
|
|
M^]E?H`(!Z*!#H0;`VMO:%K=F**UO;XL.-@``';D``-;02J^#U(&-1@`?`'+Q
|
|
M``#L@B3V.,1>`T`'`M#"!WX<@CCD@8["+"*ZM$AE"$Z:TG$<8!<HZ>E//5`,
|
|
M"V0TI'[\`"!\X($6-<`#H/B``>H+`@/0H@3Y'<8.[C$'!3SA"8MHP#CL\8]H
|
|
MK$,>"F:P`P:!PT448`%%B(T\_M&!=;AC&`!`%RZV(I4]"&`0/B!!B\!G`1DG
|
|
M5"II0"2P=H22=&S!'UE8!#=6@(T%[L`#)C"`'/HRCG^$8Y3I*((_K#`#>^0"
|
|
M*C(@!S]8(0-PB&,?@*!'%>C0`'2X@E7@0@<+!("+C7AA&(\P``H,H`N4X,`"
|
|
M$:5#"J1:`!.T5*8;Q8`!1IF)Y`)"JVY]ZSZ.<(1$^,`"!E#K/]QZCV@L(AJ_
|
|
MV(@O,N6(9_*5!R"@PSYXD``ZW(,'#:##&Q20M34<P0FL`#4=T$%J.I`#U73@
|
|
M`JOI@`4>B(`.).`!%QXBA'608P;)"$*LAZT/7W=W`!:>QB*"$8UT3"`:J+B7
|
|
M,M81`%CC>@6[/H&S=2%L8J^#'<A6=KF;_6L"0'L=VYAVM:^=[3I(8QV7\*2C
|
|
MXSF`:QPA&N?H-R#$X8\5B&,1Q!B%%A>!C0'L0YJN_,$0AE`,&T":%:I@=1WT
|
|
ML>E^=AJ:ZQC`*%41ZU"/NM2G;@#;_@``C0]@'7F`1,0G[NU0;Z/6U\"U&';M
|
|
M!6>+>]@#4(6QT[UL.K";#@:`!1>\N8YH*+W:WIQ#TD4@]&)X.]4NV+4*G'V+
|
|
M<@?]W$1?M[.3OG2A9^/IZ8BZ)6!!]74T8^2>/$9A&&*".:.K"A\O`+*GO8AT
|
|
M+"(?2>B*3!=@#SI`P!'&X*H/4H)TMQ;AK?HHPB6`0((@]B,:Y1A`?3]PA5\D
|
|
MX+B%`("OGK&(@^(C$2Y@9UT=X8TJ)V$<$P@$#W8P!-DDP@\`*$(1,*YQ?8BC
|
|
M'8EP@C@_T(4\KA8I5KA"71=A!0+X`A8(:,4.A&%X(%B"#@RXQ"@E[5:\KF,=
|
|
MEOB"%_+8KQ0CY0I3)``ZEO&/Y5)`$HO0Q_8;0NEH)`&^`*`%$/SH*V"5?Q'0
|
|
M,``&$$MR4`,Y8`"]-`<E4`#5!071@`TB-`WHP`C9L`B>M@++,`#!@#(,ITQ^
|
|
MA`5R``$D``](P$L%4`F+X`*Q%``6$$O#X!?I$`G[(`<3,$K&-P?X(!48``!8
|
|
M<(,'@`X.`"D-D0G&EV7HL!'#(`KX4``*0`YU,`+[%5$#(`<-X&MS4(4@(`<%
|
|
M``MF<P"0P`,3<$BP,`&[H`(&<`V8,`KM4`##H`C$L`[W@"Y*00!-X0M`8$?_
|
|
ML`X5X!I$\#MH=3\N0`#DLAL!<`2$@P`Y8`-8<`!S4$#'@$<[)H?$TQ1[@P`(
|
|
MP@_IAP[H\&)7T1:5"`53M#D1A`YZP`!U5!;I=S].,"Y\X1>0J$>2B`!UB`0&
|
|
ML#<&<(GWDPJ<B$CX8(N@&$'W<R9UA"#XD'Q9Q(I]D2"O>'SI(@!6L#-]80PM
|
|
M<(<1:!;(T#P:V#P%``ZW*!?VT(>#@'3?:`"[<0"G]`_I@`@`P(<&$!L&``A,
|
|
M8``@L`[M`(\&$``&Y`^`<`+[,(X,4`<BL`C>$`CK0(TCM`^+,`S1,`X#@`T+
|
|
MF5W<>"\)D(L!0"[K8$M$0`")T!=>X`__<`>&TUV*0`0'@`E2P005,(Q$(`#+
|
|
M50`]T!!P-0A\@!*R`0OS.`"0``L0@`!]>`PKF1'IX`?_`$-,@$@<\`\$H`@'
|
|
M,!;C%XE(H12R^(P\,Y(EB2#ZD"73:`#52$'82&TEQ(W$.([A:`#CN!MV$H\@
|
|
M<([I``$!P([W\@[V*`"`0`8&\`ZBDP@K61:WQP_^6`>^,I`%J94'F9`+V9`/
|
|
M>0@160=&T$BTB'2-9"QUH%5VH`_H<`090"Y84P<M\`\&X`,&P)@&H$&X``T)
|
|
ML`X$0!W>T`!XJ9$<B0_'<`0H@14'$`"1`0GWPPD`0"[CB`!P)9`$:9#3@)`*
|
|
MR9`..6&(>8]T``6+P`,KP`=]D9%`L)$&9!:PB01XR9+_X`<3@'[=-464.0\4
|
|
M,(Q:L0X:``D&I`_9M5>A]@"X@!)0(#I0``53@`Y\,`&+LPA<D)31A0@'L`X7
|
|
M``F9QA7'(#DTXYWH8`OAJ3F7F`.:\1#IL`[^$!8$P)3]!XM/R0[.>%X$D)5;
|
|
M>8W@D(U?V8W^,%'^(@PIV8G"DPA'0`#+A1E/8``(D(^O&9O^:9["`P@OFHRZ
|
|
MH:(<Z0\SNA$&U!?SL`@9F0AH!)L9T93!(HD$()7@TYF?Z0^T6`<(T"[^0)KK
|
|
MP`"0\)BA20)6FII]F0&^&9@1*)R%69P0B9P$(#KK4`-8"9S6V)7:")9:<5[^
|
|
ML)K2Z07\0*(J*@#7:0RS&9=M!@!*RHQ*X8S-91A;$`A^8`"->0",>BRA:0<&
|
|
M9`"*<`0E*15D<`&8F35D<%X&P*$C%*<?ZI7;***AB`Y+D)LHZ@^`BB=(RA5>
|
|
M8`"+,`]WJ9$KN@XJ8*.?^0<$0)IT`*F^FIIU@`&7FJGHD`"<>A7+E0"I2B;D
|
|
M4JA,VA30N`+_,)(&0`(#`$B*N9N]"9C`::;$>9@120<GL`AK6J1:@35^L`&@
|
|
M*)(D:9+HD`P24$<[H!7!:H^%U!!$RIH^B1("NHPJ9B_H,`+X0*T\XR:.\'E<
|
|
M$5VC0`@)T`B&P`_^,`J2D`!NH@D,ZR:<P+#GA0"C``D)``@\X#VI8@0#H`@$
|
|
M@`D,EUV7<``(8'CH(`@'8`0JR[+8X+(P6P?S0+(EX*`!,`"B,PJ8D`"C0`E&
|
|
MRPA&:PA&BPA&:TVCH`A&:PD)$!?\8`0DJP+/Q9E%:[,KV[*'\+($0`<WH#]4
|
|
M>[.+H`S1$`YK.P!J&PX#@`R#D`XP<&E>B[,Z>S??D`@60+4+(`U(QYE(:YJ<
|
|
MZ;0WVP-&8!AFT`/"1P=9T`-H8!@.T`/&10='T`-P8!A24)MM8JD)8#X^(+6&
|
|
M,1L\``?/1;),4`<!<+=E80^%\++<)0.#\`]%8'BS>P3,]0]8@'1N(K4H,0C'
|
|
M,(]HT+L)@!+K``S$2R;K@`O$:SGK``NSNP5UL`2<J;18RP->4`<$X!]&,%'-
|
|
M0AXFJ4X7BPX#8`&GZ``7NPX00+)=8'AHVW#9``@WL+HDZSWK4+](9SV[!0FB
|
|
M4Q:SFP8.*@EX8@!:,)O'M0*;8P`=:X$0^P]/(`!XP``N\P\'P'!*.1;KH`#J
|
|
M!+'H4`/Z0"[^^P\P4`=-P)E,RYD+[`$-_,`1/,$5C`T73`X9O,$)4%X?W(GX
|
|
M,+MX(!NSBP4:]`MX4"@G`$,HY:PV`+%7@`[4L&%\\0MO4"@2\`]%3,-)#`Q,
|
|
M3`"_0`;*]0]L`P7X>`PML#(]4`$`8`>IXC8#``R3X`+_<`HH4*\^@+3>DP"#
|
|
M.@I4>[0)`)_H0`,5>17IH`Z0LA'K$`\P-(!TK`!XL0#`<0[4H;STD#:A6[QT
|
|
M4!61#`$.>@B08CE2H0Y]_&(N(+*(Y`$BNPAW5<%7(`"CX`D)P+>@X*P*G``,
|
|
M[*PLC"4'0,$6O)0RO``P=,0U?`+Y`,(Y_`\Z4`<EP)D:&T=2H0F=/`B?7+P6
|
|
M.,IW90&J+#H)<,KJ2\0=2\7H$!WT,0@&`,KK@`-QE`Y5\`_H,`_`T0*0X`01
|
|
M(!@B(`'O_,YM(`'S7,_T?,]P$`%^$`&$$`'VK`;^+`&"8<\<`,<+:Q@S`&,:
|
|
MZSTG<([KL`*0@+\<<+-280""B,,+X!`1,+O<A3$^L-!TD`VAH+&F:03ID`K\
|
|
M(+`7:@#4*LJP?`-@],$^4+3>4P#>#,HPYK2&D2K`D)OU\E4PIK3>4P+H4``$
|
|
ML`X@L!RO>P`D$*/(``CY$``;``SW@`W+%0,P1M//Y1>(0`!&D$4LFC4>@`ZW
|
|
M,`!EL1OF^]-T\`U!_7ET4`P6>+&*$`"8L`[+,+M<7,L&L+#K4`1IH]8^`&-R
|
|
M3`<H`&-4ZSTAT-:&@24><+&`D`-23=78L`X)H`A+/18E0"8M*L79S,M)G`BF
|
|
MR!=9_7EU4*]J/0#&<!`Y,)G=:0`:NXSG<J%16:W`@"#^D`E6:3_\<(#6Y*`.
|
|
M$``'Z+38=X!%ZZ!<$`#I0`45Z0,%;++'B`[MP(NSVP)TP"G_L`(.Z@FY^0\M
|
|
M@"\\Y)$.0+7ID%K4`0,`L`+XL`YUD#;^P)M%,+LXT`<,``L(LS?Z(!5@N`Y;
|
|
M@-=T\`"<;<1(C`[9L`#=[`>.Q#:@T+!7:07\4-7G`P#WH`VYS>#CO8ZN*[9O
|
|
M?5X+S@^Q(`#_`SW2@P\#8`3Z,`$,_N$3S@\<5K?'D`FKJP\1P.`F7,-"P(OH
|
|
MH"W+E0C\30@7?@"`P#9Z\`^#X`^6G"I<\`^P0#/V+16B(`$]SEWC$KP]+@!L
|
|
MPU.X<`4`D`Y:%0H=:Y7MLA6Y.=.DO00PQK3>X]'69!@X`&.^&ZQLG@`04`<4
|
|
M\,RP?%<DSGS\8*2)8,U:2N>DK.%&"F-IKKW&/!_?7+RP+8E*P"X7$N8Z30<;
|
|
M)N8[G0X:@-P2T);H<`EZ8P2Z4!:-4`31:02V@`YG@(_P,.38;=/^T-TC,.3=
|
|
M;4O&@`@%<`123+7KX`"0P*"V8`<8P$/\D"6R?@3HH`.F?C_8P*HL"0QU,`Y#
|
|
M[@)UL`)Y$0#+10*Z;@<?$!G5WNMU&NNSC@X*4.SH@`K(GIG,KAF&<05#7@8\
|
|
M[`]%0,+HX`/2GC5&4.U!`.S=G@W@X>KKO@(`B0X>$.]TL`&N7@<14.T,<)'5
|
|
M7@'V+NRM`![WLZJ=6@?F\-\T?#_.H"*C[3V%;>YTT`'&0!)[HPN@:`,B&PI2
|
|
M6P+NN5!*64>%?M.(7J&&6B\.<0%!FK=DA@Z:H%Q9LS2"C).BLZ07ZHSHX`+@
|
|
ML0,1]%QLV@'LS<42U1#K$,53S,OW8P0J,JB%:ILH#,LJ+,L0K`"+<`,4K+(8
|
|
M?`#S"0/T$*WF(HE"3PW_T!;V0`@ORYMG[Y$:Q)E\[=]1#['WXPZ[4JB"3=H2
|
|
M)<@08-B?YP>U'-ZEZ0[\"PQICQ2X0`8%=0#P@+"U:`B>4+'``,M&`+*PH/D$
|
|
M,`H4XB:ZL+%+P[#I,),^ZZ!8(`!NP@N?>]ZCPPI&BPI&:PM&JPI&2PM&*PM&
|
|
M:PI&*PI&ZPH8:P#&D``)`0A\$``CS`-&X";%;][K,`,DR^\-P)FR[R:\SR<B
|
|
M$-&@5@<-`&.R[ST5P)F\?S:<"?R43;+='0V<*?QW*Q7U0#*9B0Y.(0P)(!5F
|
|
M<#-M`6/V#P#RW?X)(!38OZHV"NP?R7)V(X`SZ3XCX!1<'W[3?Z?.![@^_Z<`
|
|
M6M_KDV*Z[W`E+CH@`QB78:@!D,LP@`#*Y3T,@)O`?;_+!^"^FH:Z5-?U\AX;
|
|
M(!T%@!/X^M;!.*"!SFL;T$#E-0UN5B(P!)S`'_2`NS#)>L`1&%T]``O,,<Y$
|
|
M^P8!$/0'(&`1/,$P!@#&6!E+%10@:*DQ-G8*W(&8\@"=CY2%`ERPRC!&TBE>
|
|
MZ2`-M"7.9/O<!/#+"+@`D4F%/]#)TD$4:$NX0'G!@T+F^YC@?/`!NF^.N0E?
|
|
M4`.]T"!D6`IP^+F^@P!C<!]O2A7J:&CAO@5E`.R?N1*`JTPKP!CA9QB&7_^#
|
|
M8FG#!=B_`H`)L48?$`!#R_YYL\['9C09.O@'R`X7Z`"\("+(!;W8"G1`<?@`
|
|
M3D@'%)Y6:`$DH0`F`%.("D>'_5L'AK`2,BQFUOD(`#)#!Y.$7*2##\`J+$<Z
|
|
M>`'7C92@`W&`W%3`4!I4ZV`>P!!;$`21BP!(!QE`R*E`MV;6C($36`3^X`AT
|
|
ME='554I`':@'?F$%&`,HX`'N1SM@1;3J'N"O5,$'^@&,(8/>(\AX``IA#XZ`
|
|
M/*(#3\"A-0%-D`%L`08`!1D`(V)$55`1,0!'_(@9@"-Z`@R@##``-/"((3$#
|
|
M0(*4*`M0(D=4!)?)!XP^PV"??`!"K`,0P`(Q1(<(`NK`+2AIZR`30((QF``2
|
|
MW87"`$VAN2B`UF;[&J$D\VBX+\Y9``L4!DV9G](*]L,?K,($<-14`(RQ?88A
|
|
M`E!%6'8`+I&5XA.X;BRZ#-R&%:V`5CR#+\8'O$$R<UXV@UR0#1IJ'13#44`,
|
|
M8)D-R'Q?D;1Y10/G_TB`4JP#%R"UM0`C4!>9CS]P<.@CPEVBK-@N\($@@R[X
|
|
M("/L#72`BB((^K$#'LD.\`/9LA<X!2!T:R$@B4V!T7!27-\*0`;!AQY<)$B0
|
|
MVF``8PP&20!K_(%Z$!M/"NU3!`6@JRV`9!"L>$`8X`,#`!"P`!!@!.1A'X"%
|
|
M=2`=!$;O00%"@>Q;``:`]S$7/Y`9GPLX+(9201;L(J.8+B!`4E1K%,`7;(10
|
|
MT/F($2/P`A\,+L:@,!<5$:-:M(K$R'[$QV:HA\P3&"2+DS%!O,?]6+R<8IS#
|
|
M$@EB`9`X.8<+N$!_F@_FK@[0L3%0%@4D?#PO9L$*Z`,$(0_L!SU8`?8@$>D^
|
|
M.L`!6F-IPG7$P`N,F,G!57Z`8:@`1F`'.`,_``'H$20P`BER1<J#%ND]AI0/
|
|
ML'\K0"ON0M)V`)+8OR,75L`[31%\@`[>0!_;'KRP2)*O3J;2T@4!8(^94"O6
|
|
MBS.`=)K+$=!>L(`V"0`5``RL%HP)A!K$`GZ'T[#88,P$3),&P/5M!'5"^]2)
|
|
MZTL_ZB3S31&/9`$,@<=0`&R2#L"Q-U@',MI?=%86@#_90KGHUN#8FS24>M("
|
|
M,`*2L16KE`'HBQG!.@[#[%AJ)L">7"B.0/YEC<!7*,`C.D``^,@IL0,K`&-F
|
|
M8AUX`3J1Z^$!!R"AOAX%ZVH83)=-@4R4!]P!?0`"9X0SC;[9R)G(H!>P4,TH
|
|
M*<I$TA9X(@CA\0/%9OS9``JA3HH?.@@"OI(O`,LG-?JRA!-@5U-Q(<K*;0`*
|
|
MBM\B^`&WL@!@,&[0*HFDA@H`I:]*'BJ$91I=)118!T=I6B:`%$D`3(!2DE?C
|
|
MH!W\2D)'9YQ5=/&6RZ4#Q$H'!L&H`;_TEQ5,7)[+=(G!I$&[/',?"UX:2Y@G
|
|
MB9C",SJ4=PDKDC@8\_R*U0$:D1+@`/D^I'.`""&<+'X)81'\R(F$#AH`R2!&
|
|
MZ&T%U(M-2-HP@/JK`S6Q9#*`OB(5.H%6O`IU(X?Y@.>'5C*:X>.9AN$RJ;7-
|
|
M0>)B1YC#E(%+*Z`#-1#F.&$=,`%)[!,<S1>CUB"D/G!N->!JNC4(N17P!3KP
|
|
M*DNR'Z*#:7`TH:1;:P#.S_@!@"06!L;F,@)_;DVBK(#=@CNDP@$8F^8"%Y@W
|
|
MJ;`/#.)5@#%],<YQ*A]`^PS#TE""IHDZ!#&IT`T<9[F(;5:2\EFIC9"UZL`#
|
|
M4(L_8"L*`".P#I``]^MN)E`N-`0C8*U(%@S@`S6`9.6`/P`#<L!I+)2V\V4F
|
|
M`/.&MI[!VFI;QA-NR2VZ]7>NU^TD70PJ'-BI>_`.5$>*^@%9@CP>*BO@"]3`
|
|
M`5`$=D,OWDC\I0!TP#^R!^#0YP&#JX<N$!;.($M%`#FI.BZV-)Q>$T@;?<"Y
|
|
M2$D!(#`[40'(`47@;G"*4^@]P,$_*`"TRW!@"849ZWQ<&:A+]B!^`DN:]PU^
|
|
MDV`*3H1I7(V#R\*-HA&%`GI6,D@=&7U0`+301"E-*N`>;#X`4%F0`+U`9'1`
|
|
M`^R=:-!FA$!D60(J5`&@A#K@`$:<`3!Q""`/H(")8@'RP3IP)6[Q$EV:]F1#
|
|
M#X81^*%6((AB"2<01!C<1&FBZP`;,!]:Y00D@Q%0`+2@B6JAQ;)7^D$Z^`'D
|
|
M+.B)4`]`0N6``<@')W0=<`$;U$7'015(3P6`RKW#+KI%:<$/\"/70_>M`Q^`
|
|
M1RO+#2"C!6`?))]?)P_B#P49!R6`%C0`DJ4`3A=F,6JL`$G0@0S``S3`&;DL
|
|
M>P4X!,=9)P[603X4!N(G'2P#=#`(HEJ^X@%+\?N8`SRZ&S#`8_$C]T`8)`0)
|
|
MV0B2I!^-+-0`%BB`=<`"L@(L[*7_X)>&`!VQ7*0FJJ0#'T#2+-$`T$1S`>D4
|
|
M2DOQ`,`"+&$%>H8EV*+K@!)DAG]02;?!.I@DL6B-ME%S!``20#Y(!TL`'>#1
|
|
M4+,`F.@,C2SKH)#2`3>P1>O**+%MEX@?4*NKU"'-@%FHHU1`F+J5.J`$E%@5
|
|
M%'=VP(5B*"&C"P"``.@!*""0#("1<MX.#C6(/])D@""`6+,4&<`.V`>;M+#0
|
|
M@X)5*,+`-CVI;G,'J0)AZNML8,TL%.*@5ZR#*M#7H$P.&`?R*0HL@F>P`I3!
|
|
M.,B)PD/_1);;(!>6BP'(`EN@!^F#8;`X`FEI\@"T%*U4*D#P`SSI`$AO#`".
|
|
M`@`.L`YHE5Q8`77*H/:*=-`&SH%('8Y;+1BD@S#@5KNI4@T!5M789"9PD%6]
|
|
MGC;@JEXUO3T#L4I6DT$6"`5)9@<0`ZFS`HA!57,RHV0=Z`-T$:06P#;H+CC*
|
|
M'Z1*$)I\=@$<P!@NL@ZD@+J""T@".I@#]T+O`(-,L`Y(`.6I6)]U%,P-2W`,
|
|
M[$5N2FT^R1]XI&!B!RJ8W6`$V,`1`(-D)7H*53IP!@`@"!@=0!`.M&(^<`=S
|
|
MH)&")'[0"N!AMJ$#0@`)[(!@,`<47@""!ZW@NM*``2`,\BA7`"9$P!^L@P+B
|
|
M#[#/`,@'B8`)%)Q@8)W,AB_)!_Y`OF8)G,((HL$.B`:RP00X$\.7"/Y`N3`!
|
|
MQL``$((#<%$]$ATH`?!P`(#7Z]I(I=1VG0.]``!)V/#*7<0!>36O>`4OJ=<"
|
|
MDBR6"P'0)^N``I@`?^``%JQ@`*Z,X!KL@&,08#N-'JA@-V`=\()%<`<&S7#E
|
|
MFCO`&)`9$A``@``0P`3HP`LL-G_0!/P!.N``H\L2.`$G$!1AK'\-!MW%!(P"
|
|
MP^<R^A2A&09"5<I<5Z&%#))`$`@"NF"MF(`=P%`.0`2)!NK@'DX;U"8'*@!Y
|
|
MI4+W0!J,`&&@#QV&]T``>1;.UH%R,$JRP#"0`E$`'70`PX`4X6%;&`#R(+?N
|
|
MUAY[%E;`-5`"B:`*^`,LD`6TP#"8`E!@!D@##R`%J@>X,`"?I+HLCD&@#_[!
|
|
M!]`"6X`.L"1I@&+01?+Y'7Z`3-0!'%!-;$DWU5!(X(R@`^L@!TY`Z^P*TJ``
|
|
M(`'!L&#HXDI"$`S@?LQ"+S`'8`#A(`"-)-E>C[\EFH;0.E"8VF`0#(,'$`VV
|
|
M001:![0`"426="`)-E(BH`)^R@8DVU%R`,2/\1D@$NP>Y("BA'VN;;8M`'5`
|
|
M'AA1[*D-!@`'D`,Y8!%,`ZRR8#1(#O``"<@$B%MRNPTLC,5=!PTW`0P`D09-
|
|
MB(QP]4#+M`$T7(UD`7J))$@AEX89K0[@*EP70;V8/Y/&%52:)!`)XD^P,#^K
|
|
M\@K,@BSWVRBK\!BA!:`/;+1]X#@80%8EE7K1!NT8G)M\E(("R`KVH!EHJ+AP
|
|
M:GZ6`N`!)@#I9`5\L`RR5%;0!\L@*^0#(K!UB0`CL`+T8&_8`P[I<FF5+>D"
|
|
MB*0)](4J0*NHU"+H`PJ@G*G(+B!07:XE*@")`.XF`KF;:6\1E7H$14`!+)DJ
|
|
M$QE>X3A0CUP!\-:!T*8`[*VJ5`H,P'WN#7K@Z3:?;3,&\3,))`+ME0AJP/T8
|
|
M?^0B$8283Q2*DA@I8*6:@SRNW.`*#%QN7_@&(G4<5("P8*G`P3TX!H%!`*B"
|
|
M)`!U5L$$2`;>)/Y,@IL[0+S>P?RUN5;Y3)-)L&OL4SZHI`[@;^D%6-`"5`$R
|
|
M>7`1#J](`E&[7$!"/)@$]R`>G-QI0`!@``]8;0*``)P`5:`6%L`PJ`/B0-8]
|
|
M`59@"((C$?@'C8`(!(`9*P?D`1:PO#>7LCY1`Z(`%H`6]0*\:0%HJ'LP#L@/
|
|
MF:#`%&0"FP$%$+<F,$.R-/Z'3,B`=C`.#,"'$P=3%><&*9>Q"$[9`)$G329(
|
|
MZ3D7['\L@DQH`E,`!$B!.N`&6@`52`-MH`R``":0!L2`'`@#<B`/@(`6``*&
|
|
MP!N``WE`#J2!,X`&Z``(0`%C(`6`@!B0`W``#EB.32`-C`$Y\`;FP!LP`U;8
|
|
M"<N!?(80$@(,P`,E``;(`"P@4T"`K@$!"<$.*P`\#`#><!R>PW7X#N=A0=R'
|
|
MX;`<IL,(@1#K83[LAP]Q(-[#@Q@2%^(_C`40&15``VE@#H``.$"&S\`1;@,@
|
|
M(!.'8C=`!\J`&R`#98`,A)HW``+00!E@`W``!.2!-U`'0,`9,,5EX`C3@33@
|
|
M!LX`"`@#FY@,PX%</(K'`!M0$D+8#*0!-I",WX`<``%+T16#@#;`B],`'@`!
|
|
M<V`,EP%3W`+(@!2V`\0X#9@!64R+?[$<$,)U8`[P8E\,C*W`$0@"OY@,A`$X
|
|
M4(H7"")+`E9X#MP!`#8&7+$FM@-I`!@+@23P!*9`&`L#;(`-:&)5\XL3,@@`
|
|
MR*B8%;>!-X"*-?$<&,9C0!RG@53\BZTP'9#&8^`-M($V$`9.,0A@`[RX#+``
|
|
MQ5L&P@`96,C2^!R?@4Q<CQ\R0JX#94`3EV153`>D<$Y>Q2``%==C:NP&A/!'
|
|
M%L+9^!R;XDV,A,-`$*['<R#K&`%G#`):<C]^R&D@(D]CBBR$`5@PYL5T0!.C
|
|
M8F7L!@!8&G@#;F`AL^(Y0`=V,A)6Q;28#I@N.K`<[P`FOLH*8`Z@`5K,!E2Q
|
|
M&!#"YY@,I(%S/`9*L2H&RZP8&"MC9IQU$%DZ#@.W6`<\Y#.`A,O`&=#$6R`,
|
|
MX($68`=N<AG8`E]`#&SFSGR,RT`7``$N(#6?9A\`D<O`&W`!:$`!)``4H)DY
|
|
MLV?^Q299--OFTFR.A;`KWLQNH`ZT@;\L!S3Q/O[(<?DDMV3!W(M!P!L&`2$@
|
|
M!2@`1#8%MO%DKLR7V060@3<P!D"`&:#*$_D<@X"0W`;@`#,NQ:/X.\L!DKR+
|
|
MT7)C!@`C8"RG9!"`!(J`%!@"7X`*%`$L0`6^0!-X`D2@".CA-OR&90`,8`%O
|
|
MV`;$``2-!VK`@7[#-4`&,&@88`88-!>>T#'E#5]H#9T#)K2$?L,P@`Q,Z`>-
|
|
M!T+T=(;/\KDHTV?[C)_U,W_^`E`@"$@!'#R@\?`;%@(P($?#`":P'&F`CEZ.
|
|
M!]HY+\<%+:2W,)`^T?&Y#)!E(5R?[_,7.`)2(`@8`?\,H`6TKB'0)?I#XX$9
|
|
M4`,8M`P0T05:)8/H&\"@:X`8\-!EFDQ#:#6=I2?T#!C1(QI)IV@FS:*?=)2>
|
|
MTC%Z1N?@*VVC\0".UM$\&@3,`!EP`VS`%P8!-\!`+\<90`,.-9$FTC0`2.,!
|
|
M`YVCY;22GL]2H`@<`2$0!*:`@.X!SMD0SX!*C,A*`![X`J8:15]J%?V?`S2J
|
|
MUL176@&\`!4``N(3"@`!6E@4`V,T$`;&P!KPSE1Y#,"!6*P"7@`B4P!)>DG7
|
|
M:AF-@U]UC:[54.!6^V$V@`5X-$(H`<>X#I<`$0T"MK6V[LN!&B$$Z0.-$")U
|
|
MD2;2,`!7([)9#0):=1$H`9K8#;P!*]RKZ4`=0,AL0`FG8XY<K"VUL@8![C@(
|
|
MY.?]W)_==0)PUZ\:D27K^0RPW_'`?M%Y&@??/V8]!1+VNJ;5[AI>@P!Y3:\+
|
|
M\[U.R/IZ#O!K8ZVPYW2W'@,!VTY+:2H=H`]VE4[8JEI9EP"4[;"A],J.V%-@
|
|
M8NMIBXT0//5*R`/?H8P!K*)`M&-"+*$]7\`()`$F4`2^0!)P`D;@"0`%"@``
|
|
M`H'5#@`;02=H``-P2(9`3``'EB,C6``!(``P0`-(``P@;<,L"V`!_H$$:``2
|
|
MP'!D!&JP)P``W<[:*T$`X.V40+99`B&`"'G;!A?MP4VX:T+6'MJ%.W$K[I(0
|
|
MM%%`<$[(*0``..XZ`+G/&Q,>`3DA(:0$%W``.+?G[MQS9R7@X=%-NE&`Z3;=
|
|
MI#MUJ^[1C00@@.M^W;`[=A."V4V[:W?L=MU6.W<'`JS-NWNW[_[=MUL0"._A
|
|
M3;:+M_$^WL@;=FONQ<V\F_=.D`)7EP<X`1Q\!'S`XDD?-D!'-P`%P(39<J_^
|
|
MU6\`',L!,\`&WL`=V-X``")(@>P-`V;`]F;"8-DR$V/!W)I!@!A0PC``?7^>
|
|
M]9VC<\#[WMCSNBK+ZSI`A;$Q'.C5S?@9FV*`3(;=0!`FQ>A[*Z!O6"@'>#!U
|
|
M`\)".!>3X6=L4;%WCI8!_YM\OX$PL(N;,QQX`V`9@%OA\NV24S'ZW@C\&P;$
|
|
=@/_]N-G`)D;AI)@8AX$YH([/@`,WQ60&D36$?P`9
|
|
`
|
|
end
|
|
|
|
|
|
|
|
Ok, then, It is all.
|
|
Have fun !
|
|
|
|
Damiano
|
|
|
|
P.S. It should be easy to use the /dev/vga device to have
|
|
preview in gostscript, after all gostscript needs just B/W and
|
|
a framebuffer...... :-)
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 30 17:10:07 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from dg-rtp.rtp.dg.com by banjo.concert.net with SMTP (PP)
|
|
id <15550-0@banjo.concert.net>; Mon, 30 Mar 1992 17:09:38 -0500
|
|
Received: by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA07511;
|
|
Mon, 30 Mar 1992 17:09:33 -0500
|
|
Received: by ponds.UUCP (smail2.5) id AA27281; 30 Mar 92 13:34:31 EST (Mon)
|
|
To: banjo.concert.net!linux-standards-request@dg-rtp.dg.com,
|
|
linux-standards@banjo.concert.net
|
|
Subject: Re: Ok, we have been envoked.
|
|
Message-Id: <9203301334.AA27277@ponds.UUCP>
|
|
Date: 30 Mar 92 13:34:30 EST (Mon)
|
|
From: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers)
|
|
|
|
I prefer names like (as least as far as floppy/hard disks are concerned):
|
|
|
|
/dev/dsk/fd096 1.44 meg floppy disk
|
|
/dev/dsk/0s0 Entire first SCSI disk
|
|
/dev/dsk/0s1 Partition #1 of first SCSI disk
|
|
/dev/dsk/0s2 Partition #2 of first SCSI dsik
|
|
...
|
|
/dev/dsk/0p0 First MFM disk (entire disk)
|
|
/dev/dsk/0p1 First partition of first MFM disk
|
|
/dev/dsk/0p2
|
|
|
|
with analagous /dev/rdsk/xxxx for the raw devices.
|
|
|
|
Also, we might provide links from /dev/dsk/xxx to /dev/xxx for an
|
|
installed (autoconfiged?) disk. That was, all the possible names
|
|
don't clutter up the /dev directory... only the names a user would
|
|
want to see.
|
|
|
|
This is also rather SysVish - don't get the idea I thought of this
|
|
on my own... :-)
|
|
|
|
|
|
- Dave R. -
|
|
|
|
p.s. We may want to consider such a naming scheme for tapes as well.
|
|
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 30 18:55:20 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from twok.ods.com by banjo.concert.net with SMTP (PP)
|
|
id <15918-0@banjo.concert.net>; Mon, 30 Mar 1992 18:55:02 -0500
|
|
Received: by istwok.ods.com id AA24727 (5.65c/IDA-1.3.5);
|
|
Mon, 30 Mar 1992 17:57:52 -0600
|
|
From: David Engel <david@istwok.ods.com>
|
|
Message-Id: <199203302357.AA24727@istwok.ods.com>
|
|
Subject: Re: Ok, we have been envoked.
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Mon, 30 Mar 92 17:57:51 CST
|
|
In-Reply-To: <199203301413.AA16702@istwok.ods.com>; from "Alan B Clegg" at Mar 30, 92 9:07 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
> Ok, since the file system standard went over so well, I propose this
|
|
> (open for discussion):
|
|
|
|
Ok, I'll throw my two cents worth in.
|
|
|
|
The easy ones first: :)
|
|
|
|
wd0 first winchester disk, entire disk
|
|
wd0[abcd] first winchester disk, primary partitions
|
|
wd0[e-z] first winchester disk, logical partitions
|
|
wd[1-]* other winchester disks, etc.
|
|
|
|
fd0 first floppy drive, default format assigned by user
|
|
fd0[a-g] first floppy drive, formats defined in floppy.c
|
|
fd[1-N]* other floppy drives, etc.
|
|
|
|
lp0 first parallel printer port
|
|
lp[1-N] other parallel printer ports
|
|
|
|
Now, the hard ones. I've yet to see or come up with anything that I
|
|
truely like, but the following are starting to grow on me.
|
|
|
|
vt0 (or ttyv0) current virtual terminal
|
|
vt1 first virtual terminal
|
|
vt[2-N] other virtual terminal
|
|
|
|
tty0 first serial port, assigned by the user
|
|
tty[1-N] other serial ports, assigned by the user
|
|
|
|
-David
|
|
|
|
--
|
|
David Engel Optical Data Systems, Inc.
|
|
david@ods.com 1101 E. Arapaho Road
|
|
(214) 234-6400 Richardson, TX 75081
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 30 20:44:52 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from uu.psi.com by banjo.concert.net with SMTP (PP)
|
|
id <16186-0@banjo.concert.net>; Mon, 30 Mar 1992 20:40:02 -0500
|
|
Received: from access.digex.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
|
|
id AA29035; Mon, 30 Mar 92 20:11:18 -0500
|
|
Received: by access.digex.com
|
|
id AA29608 (5.65b/IDA-1.4.3/Access-1.1 - Digital Express);
|
|
Mon, 30 Mar 92 18:57:38 -0500
|
|
Date: Mon, 30 Mar 92 18:57:38 -0500
|
|
From: "Joseph R. Massi" <jrmassi@access.digex.com>
|
|
Message-Id: <9203302357.AA29608@access.digex.com>
|
|
To: jwinstea@jarthur.Claremont.EDU
|
|
Cc: abc@banjo.concert.net, linux-standards@banjo.concert.net
|
|
In-Reply-To: "Jim Winstead Jr."'s message of Mon, 30 Mar 92 9:36:47 PST <9203302000.AA22543@uu.psi.com>
|
|
Subject: Ok, we have been envoked.
|
|
|
|
I agree with Jim, keep the generic AT drives on hd and zero base the
|
|
serial ports and lp ports.
|
|
|
|
joe.
|
|
-------------------------------------------------------------------------------
|
|
Joe Massi e-mail: jrmassi@access.digex.com
|
|
Columbia, MD packet radio: kb2jg@w3iwi.md.usa.noam...
|
|
USnail/Phone/Fax: ask
|
|
disclaimer: Who me? Claim something?
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Mar 30 21:03:30 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP)
|
|
id <16302-0@banjo.concert.net>; Mon, 30 Mar 1992 21:03:13 -0500
|
|
Received: from amcl5.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA09875;
|
|
Mon, 30 Mar 92 20:03:04 CST
|
|
Date: Mon, 30 Mar 92 20:03:04 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9203310203.AA09875@stolaf.edu>
|
|
Received: by amcl5.math.stolaf.edu (4.1/SMI-4.1) id AA07102;
|
|
Mon, 30 Mar 92 20:03:03 CST
|
|
To: linux-standards@banjo.concert.net
|
|
In-Reply-To: David Engel's message of Mon, 30 Mar 92 17:57:51 CST <199203302357.AA24727@istwok.ods.com>
|
|
Subject: Ok, we have been envoked.
|
|
|
|
From: David Engel <david@istwok.ods.com>
|
|
|
|
wd0 first winchester disk, entire disk
|
|
wd0[abcd] first winchester disk, primary partitions
|
|
wd0[e-z] first winchester disk, logical partitions
|
|
wd[1-]* other winchester disks, etc.
|
|
|
|
wd or hd, I don't care -- might just stay with hd -- it seems to work
|
|
well....
|
|
|
|
fd0 first floppy drive, default format assigned by user
|
|
fd0[a-g] first floppy drive, formats defined in floppy.c
|
|
fd[1-N]* other floppy drives, etc.
|
|
|
|
With the mess of fd's that we have on PC's, there is no perfect
|
|
solution here -- but I like the orthagonality... It would be nice to
|
|
_also_ specify names that describe the drive...
|
|
|
|
lp0 first parallel printer port
|
|
lp[1-N] other parallel printer ports
|
|
|
|
Of course.
|
|
|
|
Now, the hard ones. I've yet to see or come up with anything that I
|
|
truely like, but the following are starting to grow on me.
|
|
|
|
vt0 (or ttyv0) current virtual terminal
|
|
vt1 first virtual terminal
|
|
vt[2-N] other virtual terminal
|
|
|
|
I prefer vc0, vc2, ... vcn, since the name we have been using is
|
|
virtual console. Does this make sense?
|
|
|
|
tty0 first serial port, assigned by the user
|
|
tty[1-N] other serial ports, assigned by the user
|
|
|
|
yeah...
|
|
|
|
-David
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 11:12:58 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <18584-0@banjo.concert.net>; Tue, 31 Mar 1992 10:57:27 -0500
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <23090-0@sun2.nsfnet-relay.ac.uk>; Mon, 30 Mar 1992 21:08:42 +0100
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa15165;
|
|
30 Mar 92 21:03 BST
|
|
Date: Mon, 30 Mar 92 20:56:32 +0100
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: abc@banjo.concert.net, linux-standards@banjo.concert.net
|
|
Subject: Re: Ok, we have been envoked.
|
|
|
|
Yup I like it.
|
|
Just one thing.... :-)
|
|
If you PREFIX the thing with something meaninful
|
|
Ex: The harddisk being saomething like
|
|
hd.....
|
|
the tape being something
|
|
mt....
|
|
We leave the tty or do ve have something like
|
|
ser.....
|
|
The same for the video
|
|
fb.... ( Frame buffer )
|
|
And more for the floppy
|
|
flp......
|
|
|
|
Then you can add stuff and be shure that you don't conflict.
|
|
Ex the hd can be something
|
|
hdwd1
|
|
hdwd2 ( or a, b , c .. )
|
|
hdsc1
|
|
|
|
and so on the same is valid for the rest
|
|
Something like the first three chars are to identify the device
|
|
the next three chars identify the brand name
|
|
and the remaining 2 chars identify what device it is of the possible.
|
|
Of cource if you have other flags you can append at the end :-)
|
|
( Eg. the tape can be :
|
|
mtcolr0 as for Tape, Colorado, 0 density with rewind
|
|
or
|
|
mtcolnr0 as for tape Colorado 0 density no rewind
|
|
|
|
|
|
Damiano
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 11:19:13 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
|
|
id <18738-0@banjo.concert.net>; Tue, 31 Mar 1992 11:18:31 -0500
|
|
Received: by sumax.seattleu.edu id AA18493 (5.65a/IDA-1.4.2
|
|
for linux-standards@banjo.concert.net); Tue, 31 Mar 92 08:20:27 -0800
|
|
Date: Tue, 31 Mar 92 08:20:27 -0800
|
|
From: Chuck Boyer <boyer@seattleu.edu>
|
|
Message-Id: <9203311620.AA18493@sumax.seattleu.edu>
|
|
To: abc@banjo.concert.net, db1@ukc.ac.uk, linux-standards@banjo.concert.net
|
|
Subject: Re: Ok, we have been envoked.
|
|
|
|
/hdwd0
|
|
/hdwd1
|
|
/hdwd2.....
|
|
|
|
/hdscssi0
|
|
/hdscssi1
|
|
/hdscssi2...
|
|
|
|
/at0
|
|
/at1
|
|
/xt0
|
|
/xt1
|
|
|
|
All else looks okay.... as suggested.
|
|
chuck
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 11:28:24 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from ATHENA.MIT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <18807-0@banjo.concert.net>; Tue, 31 Mar 1992 11:27:46 -0500
|
|
Received: from SOS.MIT.EDU by Athena.MIT.EDU with SMTP id AA23783;
|
|
Tue, 31 Mar 92 11:27:33 EST
|
|
Received: by SOS (5.57/4.7) id AA24957; Tue, 31 Mar 92 11:27:28 -0500
|
|
Date: Tue, 31 Mar 92 11:27:28 -0500
|
|
From: Theodore Ts'o <tytso@Athena.MIT.EDU>
|
|
Message-Id: <9203311627.AA24957@SOS>
|
|
To: Chuck Boyer <boyer@seattleu.edu>
|
|
Cc: abc@banjo.concert.net, db1@ukc.ac.uk, linux-standards@banjo.concert.net
|
|
In-Reply-To: Chuck Boyer's message of Tue, 31 Mar 92 08:20:27 -0800, <9203311620.AA18493@sumax.seattleu.edu>
|
|
Subject: Re: Ok, we have been envoked.
|
|
Reply-To: tytso@Athena.MIT.EDU
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
Date: Tue, 31 Mar 92 08:20:27 -0800
|
|
From: Chuck Boyer <boyer@seattleu.edu>
|
|
|
|
/hdwd0
|
|
/hdwd1
|
|
/hdwd2.....
|
|
|
|
/hdscssi0
|
|
/hdscssi1
|
|
/hdscssi2...
|
|
|
|
Blech! Those names are ugly! I would much rather prefer /dev/wd,
|
|
/dev/sd, etc..... People will learn fairly quickly what they are; and
|
|
in any case the "d" in "wd" and "sd" should be enough of a tipoff that
|
|
we're talking about a disk unit instead of a tape unit.
|
|
|
|
I would also make a plug for NOT using /dev/disk/XXXX. I know "modern"
|
|
AT&T Unices are trying to do this, but my experience is that it's (1)
|
|
painful to type and (2) confuses a lot of programs who expect /dev to be
|
|
a flat directory.
|
|
|
|
As for zero based versus one based for the serial ports, I would make
|
|
the argument that (for better or for worse) due to long association with
|
|
MS-DOS the hardware ports for the "first" serial port and the "second"
|
|
serial port are COM1 and COM2. While renumbering them to be zero based
|
|
may be the Unix Way, I think that it will cause way to much confusion.
|
|
I would much rather see /dev/ttys1, /dev/ttys2, /dev/ttys3, and
|
|
/dev/ttys4 for COM1, COM2, COM3, and COM4, respectively.
|
|
|
|
- Ted
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 11:47:54 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from kinglear.cs.colorado.edu by banjo.concert.net with SMTP (PP)
|
|
id <18962-0@banjo.concert.net>; Tue, 31 Mar 1992 11:47:30 -0500
|
|
Received: from localhost by kinglear.cs.Colorado.EDU with SMTP
|
|
id AA19049 (5.65c/IDA-1.4.4 for linux-standards@banjo.concert.net);
|
|
Tue, 31 Mar 1992 09:47:13 -0700
|
|
Message-Id: <199203311647.AA19049@kinglear.cs.Colorado.EDU>
|
|
To: Chuck Boyer <boyer@seattleu.edu>, linux-standards@banjo.concert.net
|
|
Subject: Re: Ok, we have been envoked.
|
|
In-Reply-To: Your message of Tue, 31 Mar 92 08:20:27 -0800. <9203311620.AA18493@sumax.seattleu.edu>
|
|
Date: Tue, 31 Mar 92 09:47:11 MST
|
|
From: drew@kinglear.cs.Colorado.EDU
|
|
|
|
|
|
--------
|
|
|
|
/hdwd0
|
|
/hdwd1
|
|
/hdwd2.....
|
|
|
|
/hdscssi0
|
|
/hdscssi1
|
|
/hdscssi2...
|
|
|
|
This is just plain nasty. Aside from the fact that SCSI is spelled with one
|
|
S and not two, normal systems traditionally name their SCSI disks
|
|
/dev/sd[drive][partition], where drive is a number,
|
|
and partition a letter. Normal disks are named in the same way,
|
|
with some other prefix. wd would not be objectionable, hd is
|
|
fairly mnemonic and works well for me.
|
|
|
|
/at0
|
|
/at1
|
|
/xt0
|
|
/xt1
|
|
|
|
Again, counter intuitive. What the hell is a /dev/at? Or a /dev/xt?
|
|
What's wrong with /dev/fd[drivenumber][somesort of density code]
|
|
--------
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 11:54:34 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from qucis.queensu.ca by banjo.concert.net with SMTP (PP)
|
|
id <19053-0@banjo.concert.net>; Tue, 31 Mar 1992 11:53:57 -0500
|
|
Received: from qusuna.qucis.queensu.ca by qucis.queensu.ca (4.1/SMI-4.1-qs1.2)
|
|
id AA14684; Tue, 31 Mar 92 11:53:34 EST
|
|
From: lalonde@qucis.queensu.ca (Paul Lalonde)
|
|
Received: by qusuna.qucis.queensu.ca (4.1/SMI-4.0-qc1.1) id AA26935;
|
|
Tue, 31 Mar 92 11:53:30 EST
|
|
Date: Tue, 31 Mar 92 11:53:30 EST
|
|
Message-Id: <9203311653.AA26935@qusuna.qucis.queensu.ca>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Com port naming
|
|
|
|
Ted writes:
|
|
> From: Chuck Boyer <boyer@seattleu.edu>
|
|
|
|
> /hdwd0
|
|
> /hdwd1
|
|
> /hdwd2.....
|
|
|
|
> /hdscssi0
|
|
> /hdscssi1
|
|
> /hdscssi2...
|
|
|
|
>Blech! Those names are ugly! I would much rather prefer /dev/wd,
|
|
>/dev/sd, etc..... People will learn fairly quickly what they are; and
|
|
>in any case the "d" in "wd" and "sd" should be enough of a tipoff that
|
|
>we're talking about a disk unit instead of a tape unit.
|
|
|
|
I agree. Very ugly. I prefer wd and wd, with links to hd[0-?].
|
|
|
|
>As for zero based versus one based for the serial ports, I would make
|
|
>the argument that (for better or for worse) due to long association with
|
|
>MS-DOS the hardware ports for the "first" serial port and the "second"
|
|
>serial port are COM1 and COM2. While renumbering them to be zero based
|
|
>may be the Unix Way, I think that it will cause way to much confusion.
|
|
>I would much rather see /dev/ttys1, /dev/ttys2, /dev/ttys3, and
|
|
>/dev/ttys4 for COM1, COM2, COM3, and COM4, respectively.
|
|
|
|
I much prefer zero based ports. Dos is brain-dead and I see no reason
|
|
to keep it that way. Even the boards are labelled 0 and 1 (at least on
|
|
my box). So use /dev/ttys[0-3], and make links to /dev/com[1-4] if
|
|
you need them. Or even put the existence of the links in the standard
|
|
if you feel very stronly about them. But /dev/ttys[1-4] is just too
|
|
much of a nasty hybrid.
|
|
|
|
Paul
|
|
|
|
Paul A. Lalonde Internet: lalonde@qucis.queensu.ca
|
|
Home Phone: (613)549-0605 Work Phone: (613)545-6754
|
|
|
|
"The only true law is that which leads to freedom"
|
|
- Richard Bach, _Jonathan Livingston Seagull_
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 12:01:52 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from kinglear.cs.colorado.edu by banjo.concert.net with SMTP (PP)
|
|
id <19182-0@banjo.concert.net>; Tue, 31 Mar 1992 12:01:27 -0500
|
|
Received: from localhost by kinglear.cs.Colorado.EDU with SMTP
|
|
id AA19074 (5.65c/IDA-1.4.4 for linux-standards@banjo.concert.net);
|
|
Tue, 31 Mar 1992 09:58:49 -0700
|
|
Message-Id: <199203311658.AA19074@kinglear.cs.Colorado.EDU>
|
|
To: Damiano Bolla <db1@ukc.ac.uk>, linux-standards@banjo.concert.net
|
|
Subject: Re: Ok, we have been envoked.
|
|
In-Reply-To: Your message of Mon, 30 Mar 92 20:56:32 +0100. <199203311629.AA12987@torreys.cs.colorado.edu>
|
|
Date: Tue, 31 Mar 92 09:58:48 MST
|
|
From: drew@kinglear.cs.Colorado.EDU
|
|
|
|
|
|
--------
|
|
|
|
Yup I like it.
|
|
Just one thing.... :-)
|
|
If you PREFIX the thing with something meaninful
|
|
Ex: The harddisk being saomething like
|
|
hd.....
|
|
the tape being something
|
|
mt....
|
|
We leave the tty or do ve have something like
|
|
ser.....
|
|
The same for the video
|
|
fb.... ( Frame buffer )
|
|
And more for the floppy
|
|
flp......
|
|
|
|
Then you can add stuff and be shure that you don't conflict.
|
|
Ex the hd can be something
|
|
hdwd1
|
|
hdwd2 ( or a, b , c .. )
|
|
hdsc1
|
|
|
|
Long and blecherous. I have Unix systems that have HPIB disks, SCSI disks,
|
|
exabytes, 1/4" tape, and serial printers all on them at the same time. There
|
|
isn't a naming conflict. Let's stick to *normal* device
|
|
namings, short, concise and to the point.
|
|
|
|
and so on the same is valid for the rest
|
|
Something like the first three chars are to identify the device
|
|
the next three chars identify the brand name
|
|
|
|
The drivers should take care of this for you, like the SCSI drivers
|
|
do, so that no matter what SCSI adapter you have (currently,
|
|
Ultrastor and Seagate adapters are supported, RSN Adaptec, and soon
|
|
DTC and CSC adapters) do, you only have one /dev/sd* set of devices,
|
|
and one set of major/minor numbers to deal with.
|
|
|
|
If I used a major and Unique device name for every host adapter that
|
|
would eventually be supported, there would be over a dozen
|
|
major numbers, /dev/hdsdadp0a, /dev/mtstsea0, etc.
|
|
|
|
This makes it very convoluted.
|
|
|
|
and the remaining 2 chars identify what device it is of the possible.
|
|
Of cource if you have other flags you can append at the end :-)
|
|
( Eg. the tape can be :
|
|
mtcolr0 as for Tape, Colorado, 0 density with rewind
|
|
or
|
|
mtcolnr0 as for tape Colorado 0 density no rewind
|
|
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 12:23:27 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP)
|
|
id <19356-0@banjo.concert.net>; Tue, 31 Mar 1992 12:22:59 -0500
|
|
Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA17565;
|
|
Tue, 31 Mar 92 12:22:47 -0500
|
|
From: asg@sage.cc.purdue.edu (Bruce Varney)
|
|
Message-Id: <9203311722.AA17565@sage.cc.purdue.edu>
|
|
Subject: Re: Ok, we have been envoked.
|
|
To: drew@kinglear.cs.Colorado.EDU
|
|
Date: Tue, 31 Mar 92 12:22:46 EST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <199203311647.AA19049@kinglear.cs.Colorado.EDU>; from "drew@kinglear.cs.Colorado.EDU" at Mar 31, 92 9:47 am
|
|
Needs: Your attention
|
|
Organization: Fraternal Order of Red-haired Milkmaids
|
|
|
|
|
|
|
|
How about this:
|
|
|
|
/dev/hdw[0-9]
|
|
/dev/hds[0-9] (for scsi disks)
|
|
etc.
|
|
|
|
Or alternatively:
|
|
/dev/whd[0-9]
|
|
/dev/shd[0-9]
|
|
etc.
|
|
|
|
Then, prepend an r for the raw disk devices:
|
|
/dev/rhdw[0-9] (for character disk devices)
|
|
etc.
|
|
|
|
As for floppies, well, the major and minor numbers should be what determines
|
|
the density, and it should be
|
|
/dev/fd0, /dev/fd1, etc.
|
|
I would have no need for a /dev/fd1ld (or whatever would designate low density).
|
|
Simply, for most people, the type of their disk drives is relativiley fixed.
|
|
(i.e., it doesn't change often). mknod /dev/fd[0-9] to the appropriate major
|
|
and minor numbers, and off you go.
|
|
|
|
As for ttys:
|
|
|
|
/dev/console should refer to the ENTIRE console, not just one virtual
|
|
window. This is so that any error message that is printed to the console
|
|
will come up on your screen (for the user at the machine itself) no matter
|
|
which virtual console you are on.
|
|
|
|
/dev/tty0 should also be the console, and then start VC's with /dev/tty1
|
|
(this makes the tty number correspond with the VC number)
|
|
|
|
Other (non console, non VC) ttys should be designated slightly differently
|
|
(these are things like the modem port). tty[a-z,A-Z] would be a good idea.
|
|
If you wish to ln /dev/com1 to /dev/ttya (or whatever) that is fine.
|
|
|
|
then for ptys, the make /dev/tty[a-z,A-Z][a-z,A-Z] the slave devices, and
|
|
/dev/pty[a-z,A-Z][a-z,A-Z] the corresponding master devices.
|
|
|
|
Of course, /dev/tty still applies to the current tty.
|
|
|
|
And then /dev/rmt[0-9] for tape drives.
|
|
|
|
Well?
|
|
|
|
Bruce
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 12:30:34 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from ATHENA.MIT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <19395-0@banjo.concert.net>; Tue, 31 Mar 1992 12:30:08 -0500
|
|
Received: from SOS.MIT.EDU by Athena.MIT.EDU with SMTP id AA28198;
|
|
Tue, 31 Mar 92 12:29:56 EST
|
|
Received: by SOS (5.57/4.7) id AA24997; Tue, 31 Mar 92 12:29:54 -0500
|
|
Date: Tue, 31 Mar 92 12:29:54 -0500
|
|
From: Theodore Ts'o <tytso@Athena.MIT.EDU>
|
|
Message-Id: <9203311729.AA24997@SOS>
|
|
To: lalonde@qucis.queensu.ca
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: Paul Lalonde's message of Tue, 31 Mar 92 11:53:30 EST, <9203311653.AA26935@qusuna.qucis.queensu.ca>
|
|
Subject: Re: Com port naming
|
|
Reply-To: tytso@Athena.MIT.EDU
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
I don't know about you, but all of my documentation for my serial cards
|
|
(admittedly, they're rice paddy specials) use COM1 and COM2 when
|
|
describing the various jumper positions. I have yet to see a hardware
|
|
documentation for serial cards which use a zero-based notation --- if
|
|
they don't use the COM1-4 designation, they use the I/O port base
|
|
address. (Perhaps I am wrong; if someone can present me with evidence
|
|
that a majority of the hardware actually uses a zero-based system,
|
|
please do so. I would be very surprised.)
|
|
|
|
I agree that DOS is bletcherous. But that's beside the point. The
|
|
question is which would be more confusing: a zero-based or one-based
|
|
numbering scheme for serial ports. I would argue that the one-based
|
|
numbering scheme goes beyond DOS --- that's the way things are screened
|
|
onto the PC boards (as jumper positions) of many serial cards, and that
|
|
few (if any) hardware documentation uses a zero-based system.
|
|
|
|
Granted, the fact that most hardware refers to COM1-4 ports is due to a
|
|
long assotiation with DOS; the hardware people didn't want to create
|
|
boards which would be confusing to the vast installed base of MS-DOS
|
|
users --- up until recently, if you purchased a PC clone, there would be
|
|
a 99.97% chance you would be running DOS. I know a lot of people
|
|
believe that a zero-based system would be aesthetically cleaner, but we
|
|
lost that chance about eight years ago. If we use a zero-based system,
|
|
it will be us who will be confusing a lot of users by bucking a
|
|
long-standing convention.
|
|
|
|
- Ted
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 14:47:57 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP)
|
|
id <19844-0@banjo.concert.net>; Tue, 31 Mar 1992 14:47:25 -0500
|
|
Received: from amcl13.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA26750;
|
|
Tue, 31 Mar 92 13:47:15 CST
|
|
Date: Tue, 31 Mar 92 13:47:15 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9203311947.AA26750@stolaf.edu>
|
|
Received: by amcl13.math.stolaf.edu (4.1/SMI-4.1) id AA16988;
|
|
Tue, 31 Mar 92 13:47:14 CST
|
|
To: linux-standards@banjo.concert.net
|
|
In-Reply-To: Paul Lalonde's message of Tue, 31 Mar 92 11:53:30 EST <9203311653.AA26935@qusuna.qucis.queensu.ca>
|
|
Subject: Com port naming
|
|
|
|
From: lalonde@qucis.queensu.ca (Paul Lalonde)
|
|
|
|
I much prefer zero based ports. Dos is brain-dead and I see no reason
|
|
to keep it that way. Even the boards are labelled 0 and 1 (at least on
|
|
my box). So use /dev/ttys[0-3], and make links to /dev/com[1-4] if
|
|
you need them. Or even put the existence of the links in the standard
|
|
if you feel very stronly about them. But /dev/ttys[1-4] is just too
|
|
much of a nasty hybrid.
|
|
|
|
I second the motion: ttys[0-4] (or whatever we call the serial ports)
|
|
and if people want to call them com[1-4], that's fine. I think that
|
|
saying that people will be confused by the zero-base is looking too
|
|
much in the short term -- if we have com[1-4] as links, people won't
|
|
get too confused now, and as people come to understand that most of
|
|
the devices (with the exception of devices where there is a concept of
|
|
"current device") are zero-based, then ttys/tts[0-3] will make more
|
|
sense. I vote for the long run, as I see it...
|
|
|
|
just my $0.02.
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 18:03:04 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from golem.wcc.govt.nz by banjo.concert.net with SMTP (PP)
|
|
id <20676-0@banjo.concert.net>; Tue, 31 Mar 1992 18:02:36 -0500
|
|
Received: from csc.wcc.govt.nz by golem.wcc.govt.nz id <AA07518-5.65a+VUW/4.0>;
|
|
Wed, 1 Apr 92 10:02:32 +1200
|
|
Received: by csc.wcc.govt.nz (MX V3.0) id 2220; Wed, 01 Apr 1992 11:03:45 EST
|
|
Sender: hamilton <hamilton@csc.wcc.govt.nz>
|
|
Date: Wed, 01 Apr 1992 11:03:38 EST
|
|
From: hamilton@csc.wcc.govt.nz
|
|
To: linux-standards@banjo.concert.net
|
|
Cc: hamilton@csc.wcc.govt.nz
|
|
Message-Id: <00958734.4AA898A0.2220@csc.wcc.govt.nz>
|
|
Subject: Ok, we have been envoked.
|
|
|
|
|
|
I had a bit of trouble getting this message out (this is a VMS box - need
|
|
I say more:), so I apologize if you receive more than one copy.
|
|
|
|
>...
|
|
>/dev/console should refer to the ENTIRE console, not just one virtual
|
|
>window. This is so that any error message that is printed to the console
|
|
>will come up on your screen (for the user at the machine itself) no matter
|
|
>which virtual console you are on.
|
|
>...
|
|
|
|
What if something goes bananas and constantly writes messages to
|
|
/dev/console. You might have trouble getting typing in edgeways in
|
|
order to correct the situation (unless you have a terminal attached to
|
|
comm[0-3]). I guess you could have some way of enabing messages to
|
|
one set of vc's only, so that one or more would remain idle.
|
|
|
|
If we're going to go with zero based, lets be consistent. No
|
|
exceptions for the comm's ports. One simple README should be able
|
|
to explain a consistent system.
|
|
|
|
I'm not sure I like the zero (0) device being special/different from
|
|
the other devices (1-n) in some cases, and not in others. Perhaps to
|
|
be consistent, the zero device should always be reserved for something
|
|
special. And if there isn't anything special, there shouldn't be one.
|
|
If this were the case comm1 would probably be the appropriate name for
|
|
comm's port 1.
|
|
|
|
If there are going to many different types of controller perhaps I would
|
|
prefer a naming hierarchy. It would certainly make it easier to handle
|
|
variants (for example /svga/video-7/vram). Drives would be similar:
|
|
|
|
/hd/wd/0
|
|
/hd/wd/1
|
|
/hd/wd/2
|
|
/hd/scsi/0
|
|
/hd/scsi/1
|
|
/hd/scsi/2
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 19:49:38 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from romeo.cs.colorado.edu by banjo.concert.net with SMTP (PP)
|
|
id <20846-0@banjo.concert.net>; Tue, 31 Mar 1992 19:49:16 -0500
|
|
Received: from localhost by romeo.cs.Colorado.EDU with SMTP
|
|
id AA18238 (5.65c/IDA-1.4.4 for linux-standards@banjo.concert.net);
|
|
Tue, 31 Mar 1992 17:49:10 -0700
|
|
Message-Id: <199204010049.AA18238@romeo.cs.Colorado.EDU>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Re: Ok, we have been envoked.
|
|
In-Reply-To: Your message of Wed, 01 Apr 92 11:03:38 -0500. <00958734.4AA898A0.2220@csc.wcc.govt.nz>
|
|
Date: Tue, 31 Mar 92 17:49:09 MST
|
|
From: drew@romeo.cs.Colorado.EDU
|
|
|
|
|
|
--------
|
|
|
|
|
|
I had a bit of trouble getting this message out (this is a VMS box - need
|
|
I say more:), so I apologize if you receive more than one copy.
|
|
|
|
>...
|
|
>/dev/console should refer to the ENTIRE console, not just one virtual
|
|
>window. This is so that any error message that is printed to the console
|
|
>will come up on your screen (for the user at the machine itself) no matter
|
|
>which virtual console you are on.
|
|
>...
|
|
|
|
What if something goes bananas and constantly writes messages to
|
|
/dev/console. You might have trouble getting typing in edgeways in
|
|
order to correct the situation (unless you have a terminal attached to
|
|
comm[0-3]). I guess you could have some way of enabing messages to
|
|
one set of vc's only, so that one or more would remain idle.
|
|
|
|
Some one should implement a syslog daemon, and log all non-fatal kernel
|
|
messages from printk() there. I think that's my next project that I'll
|
|
get to next weeken d.
|
|
|
|
|
|
If there are going to many different types of controller perhaps I would
|
|
prefer a naming hierarchy. It would certainly make it easier to handle
|
|
variants (for example /svga/video-7/vram). Drives would be similar:
|
|
|
|
/hd/wd/0
|
|
/hd/wd/1
|
|
/hd/wd/2
|
|
/hd/scsi/0
|
|
/hd/scsi/1
|
|
/hd/scsi/2
|
|
|
|
1. /dev should be flat. A non-flat /dev breaks many programs.
|
|
|
|
2. Names that long are heinous.
|
|
|
|
3. Quick question : what chipset does an Amazing Technology
|
|
SVGA card use, A Star, ASKA, etc? There are so many
|
|
repackagings, OEM versions of cards, etc that
|
|
it is not even funny. The end user should not be
|
|
concerned with this mess, the drivers should sort it
|
|
out using something like probe, as I've done with the
|
|
SCSI drivers. We want ONE device name for all frame buffers,
|
|
ONE name for all SCSI disks, and so on.
|
|
|
|
The device drivers should handle all the messy specifics, sorting out
|
|
what type of hardware you really have, like the BSD device driver's
|
|
probe(), or what I've done with the SCSI drivers. This eliminates
|
|
any need for cluttering the namespace with the inumerable
|
|
entries necessary to describe everything.
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 20:59:06 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <20942-2@banjo.concert.net>; Tue, 31 Mar 1992 20:57:11 -0500
|
|
Received: from prg.oxford.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <21282-0@sun2.nsfnet-relay.ac.uk>; Tue, 31 Mar 1992 22:02:30 +0100
|
|
Received: from lucrece.robots (lucrece-gate.robots) by prg.oxford.ac.uk
|
|
id AA21948; Tue, 31 Mar 92 22:02:37 +0100
|
|
Received: from robots.ox.ac.uk (diomedes.robots)
|
|
by uk.ac.oxford.robots (4.1/Robots 1.2m (20-Jun-90)) id AA00801;
|
|
Tue, 31 Mar 92 21:59:48 BST
|
|
Received: by robots.ox.ac.uk (4.1/robots.remoteV2.0) id AA11036;
|
|
Tue, 31 Mar 92 22:00:09 BST
|
|
Date: Tue, 31 Mar 92 22:00:09 BST
|
|
From: jon@robots.oxford.ac.uk
|
|
Message-Id: <9203312100.AA11036@diomedes.robots.ox.ac.uk>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Re: Ok, we have been envoked.
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 21:30:16 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <20942-1@banjo.concert.net>; Tue, 31 Mar 1992 20:57:04 -0500
|
|
Received: from prg.oxford.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <21293-0@sun2.nsfnet-relay.ac.uk>; Tue, 31 Mar 1992 22:02:43 +0100
|
|
Received: from lucrece.robots (lucrece-gate.robots) by prg.oxford.ac.uk
|
|
id AA21972; Tue, 31 Mar 92 22:03:05 +0100
|
|
Received: from robots.ox.ac.uk (diomedes.robots)
|
|
by uk.ac.oxford.robots (4.1/Robots 1.2m (20-Jun-90)) id AA00804;
|
|
Tue, 31 Mar 92 22:00:22 BST
|
|
Received: by robots.ox.ac.uk (4.1/robots.remoteV2.0) id AA11040;
|
|
Tue, 31 Mar 92 22:00:43 BST
|
|
Date: Tue, 31 Mar 92 22:00:43 BST
|
|
From: jon@robots.oxford.ac.uk
|
|
Message-Id: <9203312100.AA11040@diomedes.robots.ox.ac.uk>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Re: Ok, we have been envoked.
|
|
|
|
My 4pence worth,
|
|
|
|
->Ok, I'll throw my two cents worth in.
|
|
->
|
|
->The easy ones first: :)
|
|
->
|
|
->wd0 first winchester disk, entire disk
|
|
->wd0[abcd] first winchester disk, primary partitions
|
|
->wd0[e-z] first winchester disk, logical partitions
|
|
->wd[1-]* other winchester disks, etc.
|
|
|
|
I like this, if we are using DOS partioning we shouldn't try and adopt
|
|
the BSD names, having c has the whole disk seems too arbitary to me.
|
|
|
|
->fd0 first floppy drive, default format assigned by user
|
|
->fd0[a-g] first floppy drive, formats defined in floppy.c
|
|
->fd[1-N]* other floppy drives, etc.
|
|
->
|
|
->lp0 first parallel printer port
|
|
->lp[1-N] other parallel printer ports
|
|
|
|
All OK ny me.
|
|
|
|
->Now, the hard ones. I've yet to see or come up with anything that I
|
|
->truely like, but the following are starting to grow on me.
|
|
->
|
|
->vt0 (or ttyv0) current virtual terminal
|
|
->vt1 first virtual terminal
|
|
->vt[2-N] other virtual terminal
|
|
|
|
I'd prefer
|
|
vtty0 (or ttyv0) first virtual terminal
|
|
vtty[1-N] (or ttyv[1-N]) second etc virtual terminals
|
|
...
|
|
|
|
vtty (or ttyv) current virtual terminal
|
|
|
|
This would seem more in tune with the tty naming (ie I'm currently using
|
|
/dev/tty1, but /dev/tty is always the current tty).
|
|
|
|
->tty0 first serial port, assigned by the user
|
|
->tty[1-N] other serial ports, assigned by the user
|
|
|
|
I'm fairly easy on these:
|
|
tty[a-d] seems fair (like Suns), but [0-3] is more in tune with the rest.
|
|
---
|
|
<jon@uk.ac.oxford.robots>
|
|
-Jon. <...!mcsun!ukc!robots.oxford.ac.uk!jon>
|
|
<jon%robots.oxford.ac.uk@nsfnet-relay.ac.uk>
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Mar 31 22:27:50 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from uu.psi.com by banjo.concert.net with SMTP (PP)
|
|
id <21264-0@banjo.concert.net>; Tue, 31 Mar 1992 22:27:14 -0500
|
|
Received: from access.digex.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
|
|
id AA02598; Tue, 31 Mar 92 22:06:05 -0500
|
|
Received: by access.digex.com
|
|
id AA24736 (5.65b/IDA-1.4.3/Access-1.1 - Digital Express);
|
|
Tue, 31 Mar 92 16:42:54 -0500
|
|
Date: Tue, 31 Mar 92 16:42:54 -0500
|
|
From: "Joseph R. Massi" <jrmassi@access.digex.com>
|
|
Message-Id: <9203312142.AA24736@access.digex.com>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: [lalonde@qucis.queensu.ca: Com port naming]
|
|
|
|
From: lalonde@qucis.queensu.ca (Paul Lalonde)
|
|
Date: Tue, 31 Mar 92 11:53:30 EST
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Com port naming
|
|
|
|
Paul writes:
|
|
Ted writes:
|
|
>As for zero based versus one based for the serial ports, I would make
|
|
>the argument that (for better or for worse) due to long association with
|
|
>MS-DOS the hardware ports for the "first" serial port and the "second"
|
|
>serial port are COM1 and COM2. While renumbering them to be zero based
|
|
>may be the Unix Way, I think that it will cause way to much confusion.
|
|
>I would much rather see /dev/ttys1, /dev/ttys2, /dev/ttys3, and
|
|
>/dev/ttys4 for COM1, COM2, COM3, and COM4, respectively.
|
|
|
|
I much prefer zero based ports. Dos is brain-dead and I see no reason
|
|
to keep it that way. Even the boards are labelled 0 and 1 (at least on
|
|
my box). So use /dev/ttys[0-3], and make links to /dev/com[1-4] if
|
|
you need them. Or even put the existence of the links in the standard
|
|
if you feel very stronly about them. But /dev/ttys[1-4] is just too
|
|
much of a nasty hybrid.
|
|
|
|
I write:
|
|
|
|
The argument that we follow the dos conventions is a powerful one, but
|
|
we are working on a unix system, not a dos system. Even the PC BIOS
|
|
zero-bases the com port numbers. I think the naming should be simple
|
|
and constistent with commercial unix systems. A super-user can always
|
|
create additional nodes with dos-like names (eg. /dev/com1) if he/she
|
|
wants to. I wouldn't, and I don't think the standard should.
|
|
|
|
joe.
|
|
|
|
P.S. I didn't participate in the full discussion of the directory
|
|
tree, but boy, this isn't easy...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
joe.
|
|
-------------------------------------------------------------------------------
|
|
Joe Massi e-mail: jrmassi@access.digex.com
|
|
Columbia, MD packet radio: kb2jg@w3iwi.md.usa.noam...
|
|
USnail/Phone/Fax: ask
|
|
disclaimer: Who me? Claim something?
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 1 06:32:47 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <22122-1@banjo.concert.net>; Wed, 1 Apr 1992 06:32:21 -0500
|
|
Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk
|
|
via JANET with NIFTP id <5931-0@sun2.nsfnet-relay.ac.uk>;
|
|
Wed, 1 Apr 1992 09:37:39 +0100
|
|
Message-id: <01 Apr 92 09:30:59 BST ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Wed, 01 Apr 92 09:30:59 BST
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
MyName: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net>
|
|
Subject: HD device names
|
|
|
|
|
|
I am not happy about the use of names such as hd2c for partition
|
|
c of disk 2. In particular, since the number of partitions on
|
|
one disk currently allowed by the kernel is 60, this naming
|
|
scheme cannot be carried out consistently. I know some people
|
|
will say that there is no practical chance of using more than
|
|
26 partitions on a given disk, but I am not so sure.
|
|
|
|
With the increase in size of disks, and with the possibility of
|
|
using small partitions for small bits of the file system, I think
|
|
we ought not short sightedly choose a naming convention which
|
|
is likely to be awkward in the mid-term future.
|
|
|
|
What is wrong with the current /dev/hda3? It may not be BSDish,
|
|
but many existing Unixes are not. And it does have the advantage
|
|
of existing!
|
|
|
|
-- Owen
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 1 06:33:07 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <22122-3@banjo.concert.net>; Wed, 1 Apr 1992 06:32:40 -0500
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <8909-0@sun2.nsfnet-relay.ac.uk>; Wed, 1 Apr 1992 11:10:10 +0100
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa20633;
|
|
1 Apr 92 11:10 BST
|
|
Date: Wed, 01 Apr 92 11:10:05 +0100
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Devices
|
|
|
|
|
|
> The drivers should take care of this for you, like the SCSI drivers
|
|
> do, so that no matter what SCSI adapter you have (currently,
|
|
> Ultrastor and Seagate adapters are supported, RSN Adaptec, and soon
|
|
> DTC and CSC adapters) do, you only have one /dev/sd* set of devices,
|
|
> and one set of major/minor numbers to deal with.
|
|
|
|
Umhhh, the point is that people might want to have in the same system
|
|
A wd drive
|
|
A Scsi drive
|
|
A colorado tape
|
|
A soundblaster
|
|
|
|
or any other kind of hardware combination....
|
|
Believe me the amount of rubbish for PC is MUCH more that an average
|
|
workstation can even dream :-)
|
|
You can't leave it to the kernel ONLY,you need some sort of way to
|
|
tell to the kernel what to use.
|
|
|
|
You can do this at install time by creating the devices using different
|
|
major and minor depending ont he hardware you have.
|
|
OR you can have all possible combination of stuff as a preinstalled
|
|
device name.
|
|
|
|
If you choose the second method you need to make distinctions.
|
|
|
|
I think that this discussion showed that the task will be a bit hard....
|
|
|
|
What about s shell script that create devices on demand ?
|
|
Something like
|
|
|
|
makedevice scsi
|
|
|
|
Create the scsi devices
|
|
|
|
makdevice colorado
|
|
|
|
Create the colorado devices
|
|
|
|
This will keep the /dev/directory short.....
|
|
|
|
Anyway the device naming blues will not finish with this system
|
|
The device names MUST be unique for ANY possible hardware combination
|
|
After all you newer Know what you are going to install .....
|
|
|
|
I like the idea of
|
|
[device type][device brand][attributes ]
|
|
|
|
Each part being a maximum of three chars.
|
|
Ex:
|
|
|
|
fdscsi0
|
|
fdwd0
|
|
mtcolr0
|
|
flp1.2mb The 1.2mb floppy
|
|
flp1.4mb The 1.44 mb floppy
|
|
flp2.0mb The future 2.0 mb ?....
|
|
|
|
and so on....
|
|
|
|
For the serial lines it hink it will be nice to stay with
|
|
|
|
ttys1
|
|
ttys2
|
|
|
|
and so on
|
|
|
|
the pty can be something
|
|
ttyp1 The slave part have p since s is used by the serial )
|
|
ttyp2
|
|
|
|
and
|
|
|
|
ttym1 The master part of a pty
|
|
ttym2
|
|
|
|
Remembar, it the thing is cannot be extended sooner or later (by Murphy)
|
|
you will hit the limit. Therefore, it is better if the standard
|
|
can be expanded without creating conflicts.
|
|
|
|
Damiano
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 1 07:05:16 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <22122-2@banjo.concert.net>; Wed, 1 Apr 1992 06:32:28 -0500
|
|
Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk
|
|
via JANET with NIFTP id <7261-0@sun2.nsfnet-relay.ac.uk>;
|
|
Wed, 1 Apr 1992 10:19:39 +0100
|
|
Message-id: <01 Apr 92 09:44:57 BST ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Wed, 01 Apr 92 09:44:57 BST
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
MyName: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net>
|
|
Subject: Floppy disks
|
|
|
|
|
|
While we're on the subject of renaming devices, floppy disks
|
|
are long overdue for a replacement -- the MINIX names are
|
|
unmemorable and unsystematic. The suggestion has been raised
|
|
that we use fd0a, where 0 is the drive number and a is a format
|
|
defined somewhere or other (specifically in floppy.c).
|
|
|
|
This has a clean, tidy look, but there is a slight disadvantage:
|
|
remembering which format code letter refers to a disk of a given
|
|
size and density in a given drive. Is it possible to suggest --
|
|
just to prompt a reaction -- something like this:
|
|
|
|
fd0d5 Drive 0, 5.25 inch disk, double density.
|
|
fd1q3 Drive 1, 3.5 inch disk, quad density.
|
|
fd0h3 Drive 0, 3.5 inch disk, high density.
|
|
|
|
If this scheme were adopted, we should have the following table:
|
|
|
|
Old New Size bytes tracks sectors
|
|
PS0 fd0h3 3.5 1.4mb 80 18
|
|
at0 fd0h5 5.25 1.2mb 80 15
|
|
ps0 fd0q3 3.5 720kb 80 9
|
|
qh0 fd0q5 5.25 720kb 80 9
|
|
? fd0d3 3.5 360kb 40 9
|
|
pc0 fd0d5 5.25 360kb 40 9
|
|
|
|
This takes into account the various disks, but ignores the
|
|
drive capacity; I don't know what problems this would cause.
|
|
But in any case, I should find the [qdh][35] system much
|
|
easier to use and remember than any [a-h] system, which would
|
|
always involve digging out a table.
|
|
|
|
-- Owen
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 1 11:10:19 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from QUCIS.QueensU.CA by banjo.concert.net with SMTP (PP)
|
|
id <22868-0@banjo.concert.net>; Wed, 1 Apr 1992 11:09:55 -0500
|
|
Received: from qusunb.qucis.queensu.ca by qucis.queensu.ca (4.1/SMI-4.1-qs1.2)
|
|
id AA25648; Wed, 1 Apr 92 11:09:58 EST
|
|
From: lalonde@qucis.queensu.ca (Paul Lalonde)
|
|
Received: by qusunb.qucis.queensu.ca (4.1/SMI-4.0-qc1.1) id AA22371;
|
|
Wed, 1 Apr 92 11:09:55 EST
|
|
Date: Wed, 1 Apr 92 11:09:55 EST
|
|
Message-Id: <9204011609.AA22371@qusunb.qucis.queensu.ca>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: HD naming
|
|
|
|
One more thing I've not seen mentionned about hard drive naming:
|
|
How about the raw partitions? (partition as a character file)
|
|
|
|
I might suggest that given /dev/[wd|sd|hd][0-n][a-z] for the block
|
|
devices that we might get /dev/[wd|sd|hd]r[0-n][a-z] for the character
|
|
devices.
|
|
|
|
(yes I use these occasionally on other unix boxes when I need to
|
|
repair damaged file systems. Comming to think of it...does Linux
|
|
have support for raw drive access? Have to check when I get home.)
|
|
|
|
Paul
|
|
|
|
|
|
Paul A. Lalonde Internet: lalonde@qucis.queensu.ca
|
|
Home Phone: (613)549-0605 Work Phone: (613)545-6754
|
|
|
|
"The only true law is that which leads to freedom"
|
|
- Richard Bach, _Jonathan Livingston Seagull_
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 1 12:21:53 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from ladymacb.cs.colorado.edu by banjo.concert.net with SMTP (PP)
|
|
id <23247-0@banjo.concert.net>; Wed, 1 Apr 1992 12:21:11 -0500
|
|
Received: from localhost by ladymacb.cs.Colorado.EDU with SMTP
|
|
id AA02946 (5.65c/IDA-1.4.4 for linux-standards@banjo.concert.net);
|
|
Wed, 1 Apr 1992 10:17:24 -0700
|
|
Message-Id: <199204011717.AA02946@ladymacb.cs.Colorado.EDU>
|
|
To: Damiano Bolla <db1@ukc.ac.uk>, linux-standards@banjo.concert.net
|
|
Subject: Re: Devices
|
|
In-Reply-To: Your message of Wed, 01 Apr 92 11:10:05 +0100. <199204011154.AA14075@torreys.cs.colorado.edu>
|
|
Date: Wed, 01 Apr 92 10:17:22 MST
|
|
From: drew@ladymacb.cs.Colorado.EDU
|
|
|
|
|
|
--------
|
|
|
|
|
|
> The drivers should take care of this for you, like the SCSI drivers
|
|
> do, so that no matter what SCSI adapter you have (currently,
|
|
> Ultrastor and Seagate adapters are supported, RSN Adaptec, and soon
|
|
> DTC and CSC adapters) do, you only have one /dev/sd* set of devices,
|
|
> and one set of major/minor numbers to deal with.
|
|
|
|
Umhhh, the point is that people might want to have in the same system
|
|
A wd drive
|
|
A Scsi drive
|
|
A colorado tape
|
|
A soundblaster
|
|
|
|
Yes, but you don't need a
|
|
|
|
/dev/sdadaptec[0-6]
|
|
/dev/sdseagate[0-6], etc.
|
|
|
|
The point is for "similar" devices, they should have the same name iregardless
|
|
of implementation. IE SCSI disk adaptec , seagate, etc are all the same.
|
|
|
|
QIC-02 tapes from Colorado, Wantek, etc are all the same.
|
|
|
|
ST506 drives, be they IDE, MFM, RLL, ESDI are the same.
|
|
|
|
You can't leave it to the kernel ONLY,you need some sort of way to
|
|
tell to the kernel what to use.
|
|
|
|
What about s shell script that create devices on demand ?
|
|
Something like
|
|
|
|
makedevice scsi
|
|
|
|
Create the scsi devices
|
|
|
|
makdevice colorado
|
|
|
|
Create the colorado devices
|
|
|
|
This will keep the /dev/directory short.....
|
|
|
|
This would be nice. Maybe we should have a nice, interactive install
|
|
script (see Larry Wall's configure script for Perl for an example)
|
|
|
|
Anyway the device naming blues will not finish with this system
|
|
The device names MUST be unique for ANY possible hardware combination
|
|
After all you newer Know what you are going to install .....
|
|
|
|
I like the idea of
|
|
[device type][device brand][attributes ]
|
|
^^^^^
|
|
I've been saying that this field is undesireable where multiple
|
|
devices of the same type will not be installed simultaneously, and that
|
|
even if they are there should probably just be more minor numbers off of
|
|
the same device, ie
|
|
|
|
/dev/snd0
|
|
|
|
/dev/snd1
|
|
for the first two sound boards installed.
|
|
|
|
|
|
Each part being a maximum of three chars.
|
|
Ex:
|
|
|
|
fdscsi0
|
|
fdwd0
|
|
mtcolr0
|
|
|
|
What's wrong with "normal" names, like those used on any other system?
|
|
/dev/sd - scsi disks
|
|
/dev/st - scsi tapes
|
|
/dev/mt - magnetic tapes
|
|
/dev/fd - floppy disks
|
|
/dev/hd - "normal" hard disks
|
|
|
|
etc.
|
|
|
|
flp1.2mb The 1.2mb floppy
|
|
flp1.4mb The 1.44 mb floppy
|
|
flp2.0mb The future 2.0 mb ?....
|
|
|
|
A human readable size identified for the sloppy disk IS a good idea.
|
|
However, I think
|
|
|
|
/dev/fd[drive no]d{1440, 1200, 720, 360, 2880}
|
|
may work better and be more asthetically pleasing.
|
|
|
|
Another note : 2.0mb floppies exist and nearly everyone has one in
|
|
his computer these days - 2.0mb disks are unformatted 1.44's
|
|
|
|
For the serial lines it hink it will be nice to stay with
|
|
|
|
ttys1
|
|
ttys2
|
|
|
|
and so on
|
|
|
|
Agreed.
|
|
|
|
the pty can be something
|
|
ttyp1 The slave part have p since s is used by the serial )
|
|
ttyp2
|
|
|
|
and
|
|
|
|
ttym1 The master part of a pty
|
|
ttym2
|
|
|
|
Remembar, it the thing is cannot be extended sooner or later (by Murphy)
|
|
you will hit the limit. Therefore, it is better if the standard
|
|
can be expanded without creating conflicts.
|
|
|
|
Damiano
|
|
|
|
That's abnormal. We want to stick with "normal" naming conventions - ie
|
|
/dev/ttyp
|
|
/dev/ptyp
|
|
|
|
and if numbers run out
|
|
|
|
dev/ttyq
|
|
/dev/ptyq
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 1 14:22:07 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from twok.ods.com by banjo.concert.net with SMTP (PP)
|
|
id <23751-0@banjo.concert.net>; Wed, 1 Apr 1992 14:21:41 -0500
|
|
Received: by istwok.ods.com id AA07197 (5.65c/IDA-1.3.5);
|
|
Wed, 1 Apr 1992 13:24:39 -0600
|
|
From: David Engel <david@istwok.ods.com>
|
|
Message-Id: <199204011924.AA07197@istwok.ods.com>
|
|
Subject: Various Replies
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Wed, 1 Apr 92 13:24:37 CST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
>From: jon@robots.ox.ac.uk
|
|
>vtty[1-N] (or ttyv[1-N]) second etc virtual terminals
|
|
>vtty (or ttyv) current virtual terminal
|
|
>
|
|
>This would seem more in tune with the tty naming (ie I'm currently using
|
|
>/dev/tty1, but /dev/tty is always the current tty).
|
|
>
|
|
>->tty0 first serial port, assigned by the user
|
|
>->tty[1-N] other serial ports, assigned by the user
|
|
>
|
|
>I'm fairly easy on these:
|
|
>tty[a-d] seems fair (like Suns), but [0-3] is more in tune with the rest.
|
|
|
|
I'd be perfectly happy with something simple like tty[0-N] for virtual
|
|
consoles and tty[a-d] for serial ports. However, someone mentioned the
|
|
possibility of smart serial cards with more than 4 serial ports. Perhaps
|
|
we should just go with tty[a-d] and let those with smart cards devise
|
|
there own naming scheme.
|
|
|
|
=========================================================================
|
|
|
|
>From: LeBlanc@manchester-computing-centre.ac.uk
|
|
>
|
|
>I am not happy about the use of names such as hd2c for partition
|
|
>c of disk 2. In particular, since the number of partitions on
|
|
>one disk currently allowed by the kernel is 60, this naming
|
|
>scheme cannot be carried out consistently. I know some people
|
|
>will say that there is no practical chance of using more than
|
|
>26 partitions on a given disk, but I am not so sure.
|
|
>
|
|
>With the increase in size of disks, and with the possibility of
|
|
>using small partitions for small bits of the file system, I think
|
|
>we ought not short sightedly choose a naming convention which
|
|
>is likely to be awkward in the mid-term future.
|
|
|
|
I'm not entirely happy with it either. I'd prefer to have wd0[a-d]
|
|
for primary partitions and something like wd0[a-d][0-9|a-z] for
|
|
logical partitions, but the kernel doesn't number partitions that
|
|
way.
|
|
|
|
BTW, is anyone else concerned about how logical partitions are, in
|
|
effect, dynamically numbered? Creating or deleting a logical partitio,
|
|
even for another OS, could potentially raise havoc with your Linux
|
|
system by renumbering all of the logical partitions.
|
|
|
|
>What is wrong with the current /dev/hda3? It may not be BSDish,
|
|
>but many existing Unixes are not. And it does have the advantage
|
|
>of existing!
|
|
|
|
There's nothing really "wrong" with it. I prefer wd0a (or hd0a) because
|
|
it's consistent with the other devices names (ie. multiple devices of
|
|
the same type are distinguished using a digit instead of a letter).
|
|
|
|
=========================================================================
|
|
|
|
>From: LeBlanc@manchester-computing-centre.ac.uk
|
|
>
|
|
>This has a clean, tidy look, but there is a slight disadvantage:
|
|
>remembering which format code letter refers to a disk of a given
|
|
>size and density in a given drive. Is it possible to suggest --
|
|
>just to prompt a reaction -- something like this:
|
|
>
|
|
> fd0d5 Drive 0, 5.25 inch disk, double density.
|
|
> fd1q3 Drive 1, 3.5 inch disk, quad density.
|
|
> fd0h3 Drive 0, 3.5 inch disk, high density.
|
|
|
|
Hmm, I think I like it. But how about dropping the [35] part and
|
|
just differentiate them by the density? An install or makedev script
|
|
could ask the user whether the drive is 3.5" or 5.25" and setup the
|
|
right minor device numbers. Then we would have fd0[dqh] with fd0
|
|
being the user-defined default (highest) density.
|
|
|
|
-David
|
|
--
|
|
David Engel Optical Data Systems, Inc.
|
|
david@ods.com 1101 E. Arapaho Road
|
|
(214) 234-6400 Richardson, TX 75081
|
|
|
|
From LINUX-STANDARDS-request@banjo.concert.net Thu Apr 2 14:21:13 1992
|
|
Return-Path: <LINUX-STANDARDS-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <27870-0@banjo.concert.net>; Thu, 2 Apr 1992 14:20:47 -0500
|
|
Received: from sirius.ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <3590-0@sun2.nsfnet-relay.ac.uk>; Thu, 2 Apr 1992 09:12:36 +0100
|
|
Date: Thu, 2 Apr 92 9:12 BST
|
|
From: Damiano Bolla <CET601@sirius.ukc.ac.uk>
|
|
To: LINUX-STANDARDS <@nsfnet-relay.ac.uk:LINUX-STANDARDS@BANJO.CONCERT.net>
|
|
Subject: Porting Software to Linux
|
|
|
|
Hello
|
|
|
|
This article contains some suggestions for all of you that want to port
|
|
software to Linux and asck some questions about standards.
|
|
|
|
First:
|
|
My system is: gcc1.40 (the new one with the new library)
|
|
kernel 95a and the rest is as usual :-)
|
|
|
|
I ported the ghostscript2.4 to Linux, I had to since I have a strange printer.
|
|
I defined SYVR4 for my compile
|
|
I had only two problems:
|
|
1) The field st_bloks in the file sys/stat.h is missing
|
|
2) The file malloc.h is missing
|
|
NOTHING more !
|
|
|
|
The point now is this:
|
|
Can SOMEBODY please modify the include files in the DISTRIBUTION so
|
|
they are consistent with SYSVr4 ?
|
|
This will make Linux MORE and MORE "standard" !!!!
|
|
|
|
The idea is that everybody that compile uses either
|
|
-DSYSVR4
|
|
or
|
|
-DPOSIX
|
|
or
|
|
-DSYSV
|
|
|
|
They keep trak of the incompatibility they find and report them in this
|
|
maillist. SOmebody then will update the include files so the reported
|
|
problem will not appear again !
|
|
|
|
Damiano
|
|
|
|
P.S. It really would be nice if we had a different subtree for each new linux
|
|
release. What I am asking is that the ftp-man put the NEW stuff and ONLY
|
|
the new stuff under the current release. By this way we immediatly know
|
|
what is new instead of downloading megabytes and then find that we already
|
|
had the pakage....
|
|
Am I asking too much ?
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Thu Apr 2 15:02:48 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP)
|
|
id <28039-0@banjo.concert.net>; Thu, 2 Apr 1992 15:02:18 -0500
|
|
Received: from amcl11.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA07794;
|
|
Thu, 2 Apr 92 14:01:57 CST
|
|
Date: Thu, 2 Apr 92 14:01:57 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9204022001.AA07794@stolaf.edu>
|
|
Received: by amcl11.math.stolaf.edu (4.1/SMI-4.1) id AA00828;
|
|
Thu, 2 Apr 92 14:01:51 CST
|
|
To: CET601@sirius.ukc.ac.uk
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: Damiano Bolla's message of Thu, 2 Apr 92 9:12 BST <9204021923.AA07066@stolaf.edu>
|
|
Subject: Porting Software to Linux
|
|
|
|
Date: Thu, 2 Apr 92 9:12 BST
|
|
From: Damiano Bolla <CET601@sirius.ukc.ac.uk>
|
|
|
|
The point now is this:
|
|
Can SOMEBODY please modify the include files in the DISTRIBUTION so
|
|
they are consistent with SYSVr4 ?
|
|
This will make Linux MORE and MORE "standard" !!!!
|
|
|
|
The idea is that everybody that compile uses either
|
|
-DSYSVR4
|
|
or
|
|
-DPOSIX
|
|
or
|
|
-DSYSV
|
|
|
|
Um, we are not trying to create a sysVr4 clone (heaven forbid). We
|
|
_are_ working on POSIX compatibility.
|
|
|
|
Please, not sysvr4. it's just too big. All things to all people, you
|
|
know. That certainly shouldn't describe linux. Nor should the need
|
|
for huge disks...
|
|
|
|
As far "the include files in the DISTRIBUTION" go, well, it depends on
|
|
your compiler. There really is no standard right now -- that's under
|
|
development. Wait for gcc 2.1/2.2 and the ABC release if you are not
|
|
comfortable with a little playing with such things.
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
|
|
|
|
From LINUX-STANDARDS-request@banjo.concert.net Thu Apr 2 17:00:14 1992
|
|
Return-Path: <LINUX-STANDARDS-request@banjo.concert.net>
|
|
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
|
|
id <28356-0@banjo.concert.net>; Thu, 2 Apr 1992 16:37:14 -0500
|
|
Received: by sumax.seattleu.edu id AA14993 (5.65a/IDA-1.4.2
|
|
for LINUX-STANDARDS@BANJO.CONCERT.net); Thu, 2 Apr 92 13:37:56 -0800
|
|
Date: Thu, 2 Apr 92 13:37:56 -0800
|
|
From: Chuck Boyer <boyer@seattleu.edu>
|
|
Message-Id: <9204022137.AA14993@sumax.seattleu.edu>
|
|
To: CET601@sirius.ukc.ac.uk, LINUX-STANDARDS@BANJO.CONCERT.net
|
|
Subject: Re: Porting Software to Linux
|
|
|
|
No, you are not asking too much. Somebody needs to take the time to
|
|
do this, now. Everything of each new release in the same directory,
|
|
also a text file explaining this.
|
|
chuck
|
|
|
|
From LINUX-STANDARDS-request@banjo.concert.net Thu Apr 2 17:18:22 1992
|
|
Return-Path: <LINUX-STANDARDS-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <28468-0@banjo.concert.net>; Thu, 2 Apr 1992 17:17:42 -0500
|
|
Subject: Re: Porting Software to Linux
|
|
To: boyer@seattleu.edu (Chuck Boyer)
|
|
Date: Thu, 2 Apr 92 17:17:38 EST
|
|
Cc: CET601@sirius.ukc.ac.uk, LINUX-STANDARDS@BANJO.CONCERT.net
|
|
In-Reply-To: <9204022137.AA14993@sumax.seattleu.edu>; from "Chuck Boyer" at Apr 2, 92 1:37 pm
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
In previous mail, Chuck Boyer said something like:
|
|
|
|
> No, you are not asking too much. Somebody needs to take the time to
|
|
> do this, now. Everything of each new release in the same directory,
|
|
> also a text file explaining this.
|
|
|
|
Hopefully by the end of next week (before my vacation), I will have put
|
|
together a definitive release. It will contain all of the sources I have
|
|
put together for .95a, including things I have done myself, and the (three?)
|
|
contributions I have so-far.
|
|
|
|
If you have anything to contribute, please let me know ASAP.
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From LINUX-STANDARDS-request@banjo.concert.net Thu Apr 2 19:08:41 1992
|
|
Return-Path: <LINUX-STANDARDS-request@banjo.concert.net>
|
|
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
|
|
id <28741-0@banjo.concert.net>; Thu, 2 Apr 1992 19:08:02 -0500
|
|
Received: by sumax.seattleu.edu id AA03881 (5.65a/IDA-1.4.2
|
|
for LINUX-STANDARDS@BANJO.CONCERT.net); Thu, 2 Apr 92 16:08:47 -0800
|
|
Date: Thu, 2 Apr 92 16:08:47 -0800
|
|
From: Chuck Boyer <boyer@seattleu.edu>
|
|
Message-Id: <9204030008.AA03881@sumax.seattleu.edu>
|
|
To: abc@banjo.concert.net, boyer@seattleu.edu
|
|
Subject: Re: Porting Software to Linux
|
|
Cc: CET601@sirius.ukc.ac.uk, LINUX-STANDARDS@BANJO.CONCERT.net
|
|
|
|
I uploaded at 'tsx-11.mit.edu' in /incoming/guide.1a which is the
|
|
pre-release of the final draft of the (DOS) BEGINNER'S GUIDE TO
|
|
LINUX/unix that I will update as per everyone's instructions,
|
|
comments, on Sunday, April 5. This will be my final update/draft
|
|
of the guide as it is now known. It will be absorbed by other persons
|
|
who are putting together a 'definitive' guide. I will probably go
|
|
on to write up a beginner's guide in a different format, much like
|
|
published works.
|
|
|
|
I wish only that a document were provided, or in the FAQ, what
|
|
files contain what, for instance, what is it?; filutils.tar.Z,
|
|
binutils.tar.Z, newutils.tar.Z, ... (well I haven't checked just
|
|
now, but do you know what I mean?), so that 'what's in each of
|
|
those files are listed somewhere.... so people would know.
|
|
and people are told in news notes that the missing utility that are
|
|
needing is in /OLD/utilbin.tar.Z for instance.
|
|
chuck
|
|
oh, also;
|
|
|
|
wish list:
|
|
|
|
already created /dev/at0 (it 'is' there)
|
|
/dev/atlow (for 360K)
|
|
/dev/at1
|
|
/dev/at1low (for 720K)
|
|
|
|
or documentation on how to mknod /dev/at1low........ etc....
|
|
thanks
|
|
chuck
|
|
|
|
From LINUX-STANDARDS-request@banjo.concert.net Thu Apr 2 19:57:21 1992
|
|
Return-Path: <LINUX-STANDARDS-request@banjo.concert.net>
|
|
Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP)
|
|
id <28812-0@banjo.concert.net>; Thu, 2 Apr 1992 19:56:54 -0500
|
|
Received: from amcl12.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA03283;
|
|
Thu, 2 Apr 92 18:55:15 CST
|
|
Date: Thu, 2 Apr 92 18:55:15 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9204030055.AA03283@stolaf.edu>
|
|
Received: by amcl12.math.stolaf.edu (4.1/SMI-4.1) id AA26832;
|
|
Thu, 2 Apr 92 18:55:10 CST
|
|
To: boyer@seattleu.edu, LINUX-STANDARDS@BANJO.CONCERT.net,
|
|
Linux-activists@joker.cs.hut.fi, linux-activists@news-digests.mit.edu
|
|
In-Reply-To: Chuck Boyer's message of Thu, 2 Apr 92 16:08:47 -0800 <9204030008.AA03881@sumax.seattleu.edu>
|
|
Subject: Porting Software to Linux
|
|
|
|
Date: Thu, 2 Apr 92 16:08:47 -0800
|
|
From: Chuck Boyer <boyer@seattleu.edu>
|
|
|
|
I uploaded at 'tsx-11.mit.edu' in /incoming/guide.1a which is the
|
|
pre-release of the final draft of the (DOS) BEGINNER'S GUIDE TO
|
|
LINUX/unix that I will update as per everyone's instructions,
|
|
comments, on Sunday, April 5.
|
|
|
|
tsx-11.mit.edu:/pub/linux/docs/guide.1a
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Apr 3 09:40:39 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <00596-0@banjo.concert.net>; Fri, 3 Apr 1992 09:40:13 -0500
|
|
Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk
|
|
via JANET with NIFTP id <11767-0@sun2.nsfnet-relay.ac.uk>;
|
|
Thu, 2 Apr 1992 13:42:15 +0100
|
|
Message-id: <02 Apr 92 13:17:33 BST ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Thu, 02 Apr 92 13:17:33 BST
|
|
From: ZLSIIAL@cms.manchester-computing-centre.ac.uk
|
|
MyName: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net>
|
|
Subject: flat /dev, fd names
|
|
|
|
|
|
Some discussion has been going on about the format of the /dev
|
|
directory. Two notes thus far have surprised me by saying that
|
|
the presence of subdirectories under /dev would break many
|
|
programs. I am surprised at this, since most of the systems I
|
|
use have subdirectories under /dev, and I don't know of any
|
|
program that I ported that objected.
|
|
|
|
/dev can be a mess, particularly if we expect it to contain
|
|
all legal device names. Once you start having scads of pseudo
|
|
terminals for various purposes, floppy disks, hard disks, etc,
|
|
it becomes difficult to find things in the directory, and
|
|
directory listings become too unwieldy. The existing software
|
|
which refers to /dev a great deal will surely be compilable
|
|
on other systems which do not have 'flat' /dev, if it is written
|
|
at all portably. And surely the fundamental commands are those
|
|
which are most likely to mess about with /dev/xxx; as long as
|
|
we keep, e.g., /dev/tty, we shouldn't have any big problems.
|
|
|
|
Recently I wrote a note to this list which suggested a naming scheme
|
|
for floppy disks. As this note seems to have disappeared (it will
|
|
probably appear here tomorrow), let me repeat the suggestion.
|
|
|
|
The name of a floppy disk device (at least in 'flat' /dev) would be
|
|
fd[drive][density][disksize], where [drive] is 0-3, [density] is
|
|
'd', 'q', or 'h', and [disksize] is '3' or '5'. This seems to me
|
|
better than the fd[drive][codeletter] scheme, since I would have
|
|
as much difficulty remembering the code letters as I have now
|
|
with the hopeless Minix names.
|
|
|
|
-- Owen
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Apr 3 10:53:25 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <00778-0@banjo.concert.net>; Fri, 3 Apr 1992 10:52:50 -0500
|
|
Subject: Standard Proposal for Device Naming
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Fri, 3 Apr 92 10:52:45 EST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
|
|
Well, I have put my brain in gear and after hearing all of the discussion, have
|
|
come up with a proposal.
|
|
|
|
General form:
|
|
|
|
Western Digital (IDE/RLL/MFM etc) Hard Drives
|
|
/dev/{r}wd[C][N][P]
|
|
r == if specified, designates a raw (character) device
|
|
C == [a-z] Controller designation [a=first, b=second, etc]
|
|
N == [0-9] Disk Drive Number on Controller
|
|
P == [a-z] Partition number (if not given, designates entire
|
|
disk)
|
|
|
|
Examples:
|
|
/dev/wda0 First Controller, Drive 0, entire disk
|
|
/dev/rwad0 First Controller, Drive 0, Entire disk
|
|
Raw device
|
|
/dev/wda0a First Controller, Drive 0, partition 1
|
|
|
|
Non-SCSI Magnetic Tape Devices
|
|
/dev/{r}mt[C][N]
|
|
r == if specified, designates a raw (character) device
|
|
C == [a-z] Host Adapter [a=floppy controller, b=first
|
|
add-on board, etc]
|
|
N == [0-9] Tape Device number on host adapter
|
|
|
|
Examples:
|
|
/dev/rmta0 Raw Tape device, using tape device 0 on
|
|
the floppy controller
|
|
/dev/rmtb0 Raw Tape device, using tape device 0 on
|
|
add-on board
|
|
|
|
SCSI Disk Devices
|
|
/dev/{r}sd[C][N][L][P]
|
|
r == if specified, designates a raw (character) device
|
|
C == [a-z] Host Adapter [a=first, b=second, etc]
|
|
N == [0-7] SCSI ID of Disk
|
|
L == [0-7] Logical Unit Number of device
|
|
P == [a-z] Partition number (if not given, designates entire
|
|
disk)
|
|
|
|
Examples:
|
|
/dev/sda00a First Host Adapter,
|
|
SCSI ID 0, Lun 0, partition a
|
|
/dev/sdb10 Second Host Adapter,
|
|
SCSI ID 1, Lun 0, entire disk
|
|
|
|
SCSI Tape Devices
|
|
/dev/{r}st[C][N][L]
|
|
r == if specified, designates a raw (character) device
|
|
C == [a-z] Host Adapter [a=first, b=second, etc]
|
|
N == [0-7] SCSI ID of Tape Unit
|
|
L == [0-7] Logical Unit Number of device
|
|
|
|
Examples:
|
|
/dev/rsta40 Raw SCSI Tape, First Host Adapter,
|
|
SCSI ID 4, Lun 0
|
|
|
|
Floppy Disk Devices
|
|
/dev/{r}fd[N][S][D]
|
|
r == if specified, designates a raw (character) device
|
|
N == [0-1] Floppy disk number [0=a, 1=b]
|
|
S == [3,5,8] Disk Size in inches (rounded)
|
|
D == [sdq] Density (capacity depends on S and D)
|
|
h = "high" density
|
|
l = "low" density
|
|
|
|
Examples:
|
|
/dev/fd03h Drive A:, High Density, 3.5" disk (1.44Mb)
|
|
/dev/fd03l Drive A:, Low Density, 3.5" disk (720Mb)
|
|
/dev/fd15h Drive B:, High Density, 5.25" disk (1.2Mb)
|
|
/dev/fd15l Drive B:, Low Density, 5.25" disk (360k)
|
|
|
|
Console Device
|
|
/dev/console
|
|
"Master" console == /dev/vc1 unless otherwise set
|
|
|
|
Current tty
|
|
/dev/tty
|
|
standard UNIX device, your "current" terminal
|
|
|
|
Virtual Console Devices
|
|
/dev/vc[N]
|
|
N == [1-8] Virtual Console number (number represents FKey
|
|
that corresponds to given VC)
|
|
|
|
Pseudo Terminals
|
|
/dev/ttyp[N]
|
|
/dev/ptyp[N]
|
|
N == [00-99] Pseudo Terminal number. The t and p devices
|
|
represent the master and slave side of
|
|
the pseudo terminal.
|
|
|
|
"Standard" Serial Devices
|
|
/dev/ttys[N]
|
|
N == [0-3] Serial device corresponding to DOS COM1: - COM4:
|
|
|
|
Intelligent Serial Devices [add-on boards]
|
|
/dev/tty[T][N]
|
|
T == [a-z] Board Identifier [a=first, b=second, etc]
|
|
N == [00-99] Serial port number.
|
|
|
|
Examples:
|
|
/dev/ttya00 == first serial port on first add-on controller board.
|
|
/dev/ttyb16 == 17th serial port on second add-on controller board.
|
|
|
|
Parallel devices
|
|
/dev/par[N]
|
|
N == [0-2] Parallel port responding to DOS LPT1 - LPT3
|
|
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Apr 3 11:22:31 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
|
|
id <00904-0@banjo.concert.net>; Fri, 3 Apr 1992 11:21:56 -0500
|
|
Received: by sumax.seattleu.edu id AA32168 (5.65a/IDA-1.4.2
|
|
for linux-standards@banjo.concert.net); Fri, 3 Apr 92 08:22:43 -0800
|
|
Date: Fri, 3 Apr 92 08:22:43 -0800
|
|
From: Chuck Boyer <boyer@seattleu.edu>
|
|
Message-Id: <9204031622.AA32168@sumax.seattleu.edu>
|
|
To: ZLSIIAL@cms.mcc.ac.uk, linux-standards@banjo.concert.net
|
|
Subject: Re: flat /dev, fd names
|
|
|
|
What's terribly wrong with
|
|
/dev/at0
|
|
/dev/xt0
|
|
/dev/at1
|
|
/dev/xt1
|
|
for 'beginner's' it makes 'sense.' My point is that for everyone
|
|
else (hackers, programmers...etc.) they know enough, are smart
|
|
enough to change things, and it's not that big of a hastle. 'But'
|
|
for beginners, and explaining to beginners, logic, simple, at/xt
|
|
seems the 'obvious' choice. fd1h5 is okay too I guess, I concede,
|
|
but it's not so transparent... it's okay though.
|
|
chuck
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Apr 3 12:37:49 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from twok.ods.com by banjo.concert.net with SMTP (PP)
|
|
id <01236-0@banjo.concert.net>; Fri, 3 Apr 1992 12:37:05 -0500
|
|
Received: by istwok.ods.com id AA18934 (5.65c/IDA-1.3.5);
|
|
Fri, 3 Apr 1992 11:40:17 -0600
|
|
From: David Engel <david@istwok.ods.com>
|
|
Message-Id: <199204031740.AA18934@istwok.ods.com>
|
|
Subject: Re: Standard Proposal for Device Naming
|
|
To: abc@banjo.concert.net (Alan B Clegg)
|
|
Date: Fri, 3 Apr 92 11:40:16 CST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <199204031605.AA18481@istwok.ods.com>; from "Alan B Clegg" at Apr 3, 92 10:52 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
>
|
|
>
|
|
> Well, I have put my brain in gear and after hearing all of the discussion,
|
|
> have come up with a proposal.
|
|
|
|
All in all, I think I could live with it. I still have the following
|
|
comments, however:
|
|
|
|
> Floppy Disk Devices
|
|
> /dev/{r}fd[N][S][D]
|
|
> r == if specified, designates a raw (character) device
|
|
> N == [0-1] Floppy disk number [0=a, 1=b]
|
|
> S == [3,5,8] Disk Size in inches (rounded)
|
|
> D == [sdq] Density (capacity depends on S and D)
|
|
> h = "high" density
|
|
> l = "low" density
|
|
|
|
I think we should stick with the standard density names, ie. d=double,
|
|
q=quad and h=high.
|
|
|
|
I would like to see the standard explicitly allow (maybe even encourage)
|
|
users to add generic, shorthand, localized names/links for the devices
|
|
used on their system. Examples might be:
|
|
|
|
/dev/hd2b second primary partition on my third hard disk
|
|
/dev/fd1d double density diskette in my second floppy drive
|
|
/dev/tty03 my fourth serial port
|
|
|
|
This would create a definitive set of device names with consistent major/
|
|
minor numbers across all Linux systems, but also provides standard names
|
|
for people like me who don't want to specify the controller number and
|
|
size of media every time we reference a device.
|
|
|
|
-David
|
|
--
|
|
David Engel Optical Data Systems, Inc.
|
|
david@ods.com 1101 E. Arapaho Road
|
|
(214) 234-6400 Richardson, TX 75081
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Apr 3 12:43:57 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <01307-0@banjo.concert.net>; Fri, 3 Apr 1992 12:43:02 -0500
|
|
Subject: Re: Standard Proposal for Device Naming
|
|
To: david@istwok.ods.com (David Engel)
|
|
Date: Fri, 3 Apr 92 12:42:52 EST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <199204031740.AA18934@istwok.ods.com>; from "David Engel" at Apr 3, 92 11:40 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
In previous mail, David Engel said something like:
|
|
|
|
> All in all, I think I could live with it. I still have the following
|
|
> comments, however:
|
|
|
|
Thanks..
|
|
|
|
> > Floppy Disk Devices
|
|
|
|
> I think we should stick with the standard density names, ie. d=double,
|
|
> q=quad and h=high.
|
|
|
|
How many really use all three? Are there still 720k floppy disks around?
|
|
Why define more than we need? If the need is there, I agree (infact, my
|
|
original draft [internal use only] had Low, Double, and Quad, until I tried
|
|
to find a use for all three... LET ME KNOW!
|
|
|
|
> I would like to see the standard explicitly allow (maybe even encourage)
|
|
> users to add generic, shorthand, localized names/links for the devices
|
|
> used on their system. Examples might be:
|
|
>
|
|
> /dev/hd2b second primary partition on my third hard disk
|
|
> /dev/fd1d double density diskette in my second floppy drive
|
|
> /dev/tty03 my fourth serial port
|
|
|
|
I disagree. This leads to confusion (ESPECIALY ON SERIAL DEVICES) of locking
|
|
mechanisms. Is every version of UUCP, kermit and pcomm supposed to know
|
|
that /dev/tty03 == /dev/ttys3 when creating /usr/spool/uucp/LCK..tty03?
|
|
|
|
This is a __MAJOR__ problem. I recommend that we find one set of devices and
|
|
make that the *STANDARD* and let people evolve into using them. We did the
|
|
same for the directory tree (not that I have seen any use of it, but..) and
|
|
everyone seems to get along OK with it...
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Apr 3 13:14:35 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP)
|
|
id <01463-0@banjo.concert.net>; Fri, 3 Apr 1992 13:13:09 -0500
|
|
Received: from amcl10.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA20891;
|
|
Fri, 3 Apr 92 12:13:00 CST
|
|
Date: Fri, 3 Apr 92 12:13:00 CST
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9204031813.AA20891@stolaf.edu>
|
|
Received: by amcl10.math.stolaf.edu (4.1/SMI-4.1) id AA07102;
|
|
Fri, 3 Apr 92 12:13:00 CST
|
|
To: linux-standards@banjo.concert.net
|
|
In-Reply-To: David Engel's message of Fri, 3 Apr 92 11:40:16 CST <199204031740.AA18934@istwok.ods.com>
|
|
Subject: Standard Proposal for Device Naming
|
|
|
|
From: David Engel <david@istwok.ods.com>
|
|
|
|
> Floppy Disk Devices
|
|
> /dev/{r}fd[N][S][D]
|
|
> r == if specified, designates a raw (character) device
|
|
> N == [0-1] Floppy disk number [0=a, 1=b]
|
|
> S == [3,5,8] Disk Size in inches (rounded)
|
|
|
|
What about the 2 inch floppies in some laptops? We ignoring them?
|
|
Ok, fine. That's a good idea, actually, since they never took off and
|
|
I think act like 3.5's at quad density anyway. (someone correct me if
|
|
I'm wrong...)
|
|
|
|
> D == [sdq] Density (capacity depends on S and D)
|
|
> h = "high" density
|
|
> l = "low" density
|
|
|
|
I think we should stick with the standard density names, ie. d=double,
|
|
q=quad and h=high.
|
|
|
|
now also e=extra, for the 2.88. Linux will support them someday, if
|
|
it doesn't already... (I don't have any... wouldn't know)
|
|
|
|
I would like to see the standard explicitly allow (maybe even encourage)
|
|
users to add generic, shorthand, localized names/links for the devices
|
|
used on their system. Examples might be:
|
|
|
|
Of course. That's the thing that I think gets missed as we discuss
|
|
all this. There has been talk as if the device name has to be instantly
|
|
transparent to every user, even if that requires a name 20 char's
|
|
long. Well, I'm exagerating, but really, we need a standard that
|
|
makes sense to the hacker and will be reasonble to program with, not
|
|
one that is instantly transparent to joe dos user -- That is what
|
|
documentation is for. I am not saying that we should unnecessarily
|
|
make things difficult -- not by any means -- but that most users
|
|
should not have to deal with /dev names very often, and that when they
|
|
do, they shouldn't have to type extremely long names.
|
|
|
|
This most recent proposal of Alan's I think fits the bill very nicely.
|
|
We need an absolutely standard and reasonable orthogonal system of
|
|
naming, and this provides it. I am certainly not attacking joe dos
|
|
user, as that is where I have come from too, though with some exposure
|
|
to unix as a standard user for the last few years. And in the
|
|
documentation, I am putting a high priority on reaching joe dos user.
|
|
I just think... Well, re-read the last paragraph :-).
|
|
|
|
One small suggestion/idea:
|
|
|
|
should we specify a link from /dev/lp to whatever the "standard
|
|
printer" that the user wants to use normally is? That way, things
|
|
print on /dev/lp without having to be configured to use
|
|
/dev/par[something] or /dev/ttys[something] for those with serial
|
|
printers. I imagine that the default value of this link would be a
|
|
link to the first par port...
|
|
|
|
Comments?
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
|
|
From linux-standards-request@banjo.concert.net Fri Apr 3 15:10:46 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from twok.ods.com by banjo.concert.net with SMTP (PP)
|
|
id <02473-0@banjo.concert.net>; Fri, 3 Apr 1992 15:09:59 -0500
|
|
Received: by istwok.ods.com id AA19629 (5.65c/IDA-1.3.5);
|
|
Fri, 3 Apr 1992 14:13:13 -0600
|
|
From: David Engel <david@istwok.ods.com>
|
|
Message-Id: <199204032013.AA19629@istwok.ods.com>
|
|
Subject: Re: Standard Proposal for Device Naming
|
|
To: abc@banjo.concert.net (Alan B Clegg)
|
|
Date: Fri, 3 Apr 92 14:13:12 CST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <199204031746.AA18990@istwok.ods.com>; from "Alan B Clegg" at Apr 3, 92 12:42 pm
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
> How many really use all three? Are there still 720k floppy disks around?
|
|
> Why define more than we need? If the need is there, I agree (infact, my
|
|
> original draft [internal use only] had Low, Double, and Quad, until I tried
|
|
> to find a use for all three... LET ME KNOW!
|
|
|
|
There probably aren't too many quads used, but who knows, somebody out
|
|
there may actually be using them. As Michael mentioned, we also have to
|
|
consider the new 2.88 Meg drives also.
|
|
|
|
> I disagree. This leads to confusion (ESPECIALY ON SERIAL DEVICES) of locking
|
|
> mechanisms. Is every version of UUCP, kermit and pcomm supposed to know
|
|
> that /dev/tty03 == /dev/ttys3 when creating /usr/spool/uucp/LCK..tty03?
|
|
|
|
We may just have to agree to disagree on this one. :)
|
|
|
|
I see two worthwhile, but conflicting, goals here. The first is to have a
|
|
definitive set of specific device names (and numbers) supported by Linux.
|
|
The second is to have generic name, coomon across all systems, for the
|
|
devices that are actually in use. The problem with the first goal is that
|
|
similarly used devices on separate systems have totally different names.
|
|
Conversely, the problem with the second is that the devices would have
|
|
different numbers.
|
|
|
|
What I'm proposing is a compromise. Keep the highly specific device name
|
|
you proposed, but allow each user to set up symlinks, probably with the
|
|
aid of configuration script, between the generic and specific names.
|
|
|
|
I'll admit having generic names for hard disks is probably not very useful
|
|
since their use is highly dependent partitioning and file system set up.
|
|
However, I fell generic names for other devices such as ttys, floppies and
|
|
tapes is very useful.
|
|
|
|
Maybe an example might help. Let's say I write "Dave's Nifty Backer-Upper"
|
|
for Linux and I want to present the user with a list of destination devices
|
|
to make it as user-friendly as possible. With standard, generic names, I
|
|
can limit the choices to those valid for his/her system. Without genric
|
|
names, I have to include all combinations of floppy, tape (both SCSI and
|
|
non-SCSI), most of which aren't valid. Not very user-friendly, IMO.
|
|
|
|
As for your example, UUCP, kermit, pcomm, etc. would all be configured to
|
|
use tty03. They have no need to know that it is actually ttys3. Ttys3
|
|
would never be referenced directly in normal use. It is only there to
|
|
remind you what tty03 really is the next time you reconfigure the hardware
|
|
installed in your system.
|
|
|
|
-David
|
|
--
|
|
David Engel Optical Data Systems, Inc.
|
|
david@ods.com 1101 E. Arapaho Road
|
|
(214) 234-6400 Richardson, TX 75081
|
|
|
|
From linux-standards-request@banjo.concert.net Sat Apr 4 09:47:17 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP)
|
|
id <04650-0@banjo.concert.net>; Sat, 4 Apr 1992 09:46:52 -0500
|
|
Received: from ferrari.daimi.aau.dk by daimi.aau.dk
|
|
with SMTP (5.61++/IDA-1.2.8) id AA15569; Sat, 4 Apr 92 16:46:46 +0200
|
|
Received: by ferrari.daimi.aau.dk (5.64/1.34) id AA13200;
|
|
Sat, 4 Apr 92 16:46:44 +0200
|
|
Date: Sat, 4 Apr 92 16:46:44 +0200
|
|
From: tthorn@daimi.aau.dk
|
|
Message-Id: <9204041446.AA13200@ferrari.daimi.aau.dk>
|
|
To: linux-standards@banjo.concert.net
|
|
In-Reply-To: ZLSIIAL@cms.mcc.ac.uk's message of Thu, 02 Apr 92 13:17:33 BST <02 Apr 92 13:17:33 BST ZLSIIAL@UK.AC.MCC.CMS>
|
|
Subject: Re: flat /dev, fd names
|
|
|
|
Date: Thu, 02 Apr 92 13:17:33 BST
|
|
From: ZLSIIAL@cms.mcc.ac.uk
|
|
Myname: A. V. Le Blanc
|
|
|
|
The name of a floppy disk device (at least in 'flat' /dev) would be
|
|
fd[drive][density][disksize], where [drive] is 0-3, [density] is
|
|
'd', 'q', or 'h', and [disksize] is '3' or '5'. This seems to me
|
|
better than the fd[drive][codeletter] scheme, since I would have
|
|
as much difficulty remembering the code letters as I have now
|
|
with the hopeless Minix names.
|
|
|
|
Yes, everybody agrees that the Minux convention is brain dead, but
|
|
I don't like your surgestion. Nobody uses density to destinguish
|
|
formats anymore as you could easily have different formats with
|
|
the same density. Instead I would prefer devicenames that included
|
|
some more meaningful information of the format, such as XXX1440,
|
|
XXX1200, or something likewise.
|
|
|
|
/Tommy Thorn
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Sat Apr 4 19:18:59 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <05790-0@banjo.concert.net>; Sat, 4 Apr 1992 19:18:28 -0500
|
|
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
|
|
id <11106-0@sun2.nsfnet-relay.ac.uk>; Sat, 4 Apr 1992 18:02:37 +0100
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa12169;
|
|
4 Apr 92 12:05 BST
|
|
Date: Sat, 04 Apr 92 11:49:29 +0100
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: /dev
|
|
|
|
I agree with LeBlanc.
|
|
|
|
I think that having subdirectoryes in /dev/is possible and desiderable.
|
|
If any of your program complains you can always symlink.....
|
|
|
|
The all thing is MUCH easier to understand and to maintain.
|
|
|
|
BTW: The all point to have this is that the resulting structure
|
|
has MORE meaning than the original.
|
|
|
|
What I mean is that the all point of this discussion is to end up with
|
|
a naming schema that :
|
|
|
|
Can be EXPANDED without a change of the rules.
|
|
It is EASY to understand what a device is WITHOUT looking at the manual.
|
|
|
|
.....
|
|
|
|
|
|
Then welcome to
|
|
|
|
/dev/fd/scsi...
|
|
/dev/fd/wd..
|
|
|
|
/dev/flp/1.4m
|
|
/dev/flp/720k
|
|
/dev/flp/1.2m
|
|
|
|
/dev/mt/wan....
|
|
/dev/mt/col....
|
|
|
|
/dev/mouse/....
|
|
|
|
/dev/midi/sb..
|
|
/dev/midi/...
|
|
|
|
/dev/pty/pty1
|
|
/dev/pty/ptym1
|
|
/dev/pty/pty2
|
|
/dev/pty/ptym2
|
|
|
|
Just one thing......
|
|
|
|
we keep the virtual consoles and all serial lines are in /dev
|
|
/dev/console
|
|
/dev/tty
|
|
/dev/tty1 # virtual console
|
|
/dev/tty2 # virtual console
|
|
.......
|
|
|
|
/dev/ttys1 # Serial line
|
|
/dev/ttys2 # Serial line
|
|
/dev/ttys3
|
|
|
|
I don't think that having a special piece of hardware for more serial
|
|
lines wil pose a problem, You will have a different major but you can
|
|
allocate the serials where you want.
|
|
NOTE: This is possible since ALL serial lines have a common set of
|
|
operations available. Ie. the soft DO NOT need to distinguish between
|
|
the different brand ( Here software means user programs )
|
|
|
|
Damiano
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 5 07:27:32 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <06813-0@banjo.concert.net>; Sun, 5 Apr 1992 07:27:06 -0400
|
|
Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk
|
|
via JANET with NIFTP id <1497-0@sun2.nsfnet-relay.ac.uk>;
|
|
Sun, 5 Apr 1992 11:55:47 +0100
|
|
Message-id: <05 Apr 92 11:44:47 BST ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Sun, 05 Apr 92 11:44:47 BST
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
MyName: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net>
|
|
Subject: fd dev
|
|
|
|
|
|
Someone has written asking me what is wrong with
|
|
/dev/at0
|
|
/dev/xt0
|
|
as names for floppy disks. Well, I am not a beginner either
|
|
with DOS or with unix, but the only clue I have to what they
|
|
mean is that, for Minix, /dev/at0 is a 1.2mb 5.25in drive.
|
|
Does this mean that /dev/xt0 is a 1.4mb 3.5in drive?
|
|
These names are meaningless to me, and ought to be eliminated.
|
|
|
|
Someone else has written to say, with repect to my suggestion
|
|
/dev/fd0h3
|
|
/dev/fd0q5
|
|
/dev/fd1d3
|
|
that we ought to eliminate the final digit. Unfortunately this
|
|
means that on some systems /dev/fd0h would be a three inch disk,
|
|
on others a 5 inch disk, so that the same name would refer to
|
|
different devices. This in turn would lead to software (eg
|
|
versions of mtools) that would work on one system but not on
|
|
another, and for a reason which would be very hard for us net
|
|
friends to track down (at least the first time). If someone
|
|
wants to link fd0h to whatever is appropriate for his machine,
|
|
let him do so, but software should not be distributed which
|
|
refers to system specific devices.
|
|
|
|
Someone asked who uses various disk sizes. Around here we have
|
|
many 3.5 inch disks at all three densities (double, quad, high)
|
|
and many 5.25 inch disks at two densities (double, high). This
|
|
is partly because of media prices and partly for historical
|
|
reasons, but I don't see any prospect of the odd densities
|
|
disappearing for a few years. You may not be in this fix, but
|
|
many other educational institutions will probably be.
|
|
|
|
-- Owen
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 5 08:01:19 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from kruuna.Helsinki.FI by banjo.concert.net with SMTP (PP)
|
|
id <06839-0@banjo.concert.net>; Sun, 5 Apr 1992 08:00:55 -0400
|
|
Received: from klaava.Helsinki.FI by kruuna.helsinki.fi with SMTP
|
|
id AA17391 (5.65c/IDA-1.4.4 for <linux-standards@banjo.concert.net>);
|
|
Sun, 5 Apr 1992 15:00:40 +0300
|
|
Received: by klaava.Helsinki.FI (4.1/SMI-4.1) id AA07225;
|
|
Sun, 5 Apr 92 15:00:39 +0300
|
|
Date: Sun, 5 Apr 92 15:00:39 +0300
|
|
From: torvalds@cc.helsinki.fi (Linus Torvalds)
|
|
Message-Id: <9204051200.AA07225@klaava.Helsinki.FI>
|
|
In-Reply-To: LeBlanc@manchester-computing-centre.ac.uk's message as of Apr 5, 11:44
|
|
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
|
|
To: linux-standards <linux-standards@banjo.concert.net>
|
|
Subject: Re: fd dev
|
|
|
|
Ok, I didn't want to get into this very much, but I'd like to say my 2c
|
|
in the discussion (I'll conform to whatever the group decides on, but I
|
|
hope I'll like it too...)
|
|
|
|
- I decidedly dislike the non-flat proposals: I know it looks nice when
|
|
you do an 'ls' on the device directory, but it does break a lot of
|
|
programs (rootdev, tty etc all goe through the dev-directory to find out
|
|
the correct names). And these programs aren't just small programs
|
|
written for linux: the GNU library function ttyname() depends on the
|
|
tty's being in a flat directory etc..
|
|
|
|
- I'd like this kind of floppy-structure (I think it's been proposed by
|
|
others, but repeating it won't hurt):
|
|
|
|
/dev/fdndxxxx
|
|
|
|
where n is the floppy drive number, d is the density/size of the /drive/
|
|
and xxxx is the size of the disk. The encoding of 'd' might be a
|
|
problem: you have to distinguish 5.25" and 3.5" high density drives
|
|
(both can read 360/720kB disks), but I think the name could be pretty
|
|
easy to remember. Of course, everybody would link their own names
|
|
depending on what kind of drive they have, but this could be the general
|
|
"standard" names.
|
|
|
|
This could result in names like ('d' is uppercase means 3.5" - just a
|
|
thought):
|
|
|
|
/dev/fd0H1440 (1.44MB disk in 3.5" drive)
|
|
/dev/fd0d360 (360kB disk in double-denstiry 5.25" drive)
|
|
/dev/fd0h360 (360kB disk in high-denstiry 5.25" drive)
|
|
/dev/fd0H360 (360kB disk in 3.5" drive)
|
|
|
|
etc. Pretty easy to remember, and it does give the user a picture of
|
|
what kind of drive it's all about, once he knows the general rules.
|
|
|
|
- I disagree slightly with the /dev/wdxy structure, where 'x' is a
|
|
harddisk number, and 'y' is a alphabetic character for the partition for
|
|
two reasons:
|
|
|
|
- it seems 'y' = c means the whole disk under BSD. Very confusing
|
|
if it just means partition nr 3 under linux.
|
|
- although unlikely, there can be more than 27 partitions/disk.
|
|
|
|
I'd rather see the current naming remain, with the change that 'hd' is
|
|
just renamed as 'wd'. Nobody has had any major complaints with the
|
|
current naming, I think, except for the possibility of confusion with
|
|
SCSI etc drives if we just call them 'hd'. I think it's logical to call
|
|
harddisk 0 /dev/wda, and it's partitions /dev/wdaXX.. (with a possible
|
|
'r' before the name for raw devices, although linux doesn't support them
|
|
as separate devices right now...)
|
|
|
|
Linus
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 5 10:56:44 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP)
|
|
id <06923-0@banjo.concert.net>; Sun, 5 Apr 1992 10:56:17 -0400
|
|
Received: by daimi.aau.dk (5.61++/IDA-1.2.8) id AA08494;
|
|
Sun, 5 Apr 92 16:56:03 +0200
|
|
From: Tommy Thorn <tthorn@daimi.aau.dk>
|
|
Message-Id: <9204051456.AA08494@daimi.aau.dk>
|
|
Subject: Re: fd dev
|
|
To: torvalds@cc.helsinki.fi (Linus Torvalds)
|
|
Date: Sun, 5 Apr 92 16:56:02 BST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <9204051200.AA07225@klaava.Helsinki.FI>; from "Linus Torvalds" at Apr 5, 92 3:00 pm
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
YES!! Linus suggestion hits the nailhead. I support it 100%.
|
|
|
|
/Tommy Thorn
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 5 13:46:39 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <07065-0@banjo.concert.net>; Sun, 5 Apr 1992 13:46:07 -0400
|
|
Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk
|
|
via JANET with NIFTP id <4306-0@sun2.nsfnet-relay.ac.uk>;
|
|
Sun, 5 Apr 1992 14:41:55 +0100
|
|
Message-id: <05 Apr 92 12:06:17 BST ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Sun, 05 Apr 92 12:06:17 BST
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
MyName: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net>
|
|
Subject: proposed names
|
|
|
|
|
|
I read with interest the proposal for device names. I am unhappy
|
|
about two of them:
|
|
|
|
/dev/{r}wd[C][N][P]
|
|
|
|
where C is [a-z], N is [0-9], and P is [a-z]. It would be better to
|
|
have C as [0-9], N as [a-z], and P as [1-xx]. Otherwise we must
|
|
change or violate the standard when dealing with more than 26
|
|
partitions. The code in the kernel now deals with up to 60 partitions.
|
|
|
|
/dev/{r}fd[N][S][D]
|
|
|
|
where N is [0-3], S is [358], and P is [hqld] It would be better to have
|
|
P before S to preserve letter/digit alternation.
|
|
|
|
-- Owen
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 5 13:47:00 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <07065-1@banjo.concert.net>; Sun, 5 Apr 1992 13:46:13 -0400
|
|
Received: from thor.cardiff.ac.uk by sun2.nsfnet-relay.ac.uk via JANET
|
|
with NIFTP id <7806-0@sun2.nsfnet-relay.ac.uk>;
|
|
Sun, 5 Apr 1992 16:52:19 +0100
|
|
From: Paul Richards <spedpr@thor.cardiff.ac.uk>
|
|
Message-Id: <24759.9204051553@thor.cf.ac.uk>
|
|
Subject: floppy names
|
|
To: linux-standards@banjo.concert.net (linux-standards)
|
|
Date: Sun, 5 Apr 92 16:53:40 WET DST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
|
|
I've obviously missed something fundamental but I don't see why we need
|
|
device specific names. Why can't we just have /dev/fpx where x is a
|
|
number or letter or whatever. There's only one device driver for floppy
|
|
disks and I can't see why this would be likely to change. Surely we
|
|
should differentiate between drivers and not different types of
|
|
underlying hardware.
|
|
|
|
If there are large numbers of different names for floppies then writing
|
|
portable software for them is going to be a nightmare since all the
|
|
different names for each possible drive will have to be catered for. I
|
|
can't see why this is necessary. No software that I know of needs to
|
|
know the capacity of the drive. Even if there is and I've just thought
|
|
of a few cases, then surely the driver should supply this information.
|
|
|
|
As an example, say I change my old 5.25 disk for a nice new 2.88M 3.5.
|
|
If we use the hardware based scheme then I'll have to modify all my
|
|
software to use the new device name. Ok I hear you say, make a link.
|
|
Well if we all link these hardware based names to something like /dev/fp
|
|
then why not just make it the standard in the first place.
|
|
|
|
If we use /dev/fp and I change my drive nothing has to change except the
|
|
major/minor device number. All software still accesses /dev/fp and the
|
|
driver takes care of the underlying hardware.
|
|
|
|
To sum up, I think device names should be based on whether there are
|
|
different drivers and not on different hardware.
|
|
|
|
--
|
|
Paul Richards at Cardiff university, UK.
|
|
|
|
spedpr@uk.ac.cf.thor Internet: spedpr%thor.cf.ac.uk@nsfnet-relay.ac.uk
|
|
UUCP: spedpr@thor.cf.UUCP or ...!uunet!mcsun!ukc!cf!thor!spedpr
|
|
+++
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 5 16:29:36 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from vxicp1.ictp.trieste.it by banjo.concert.net with SMTP (PP)
|
|
id <07179-0@banjo.concert.net>; Sun, 5 Apr 1992 16:29:08 -0400
|
|
Return-path: pietrak@itsictp.bitnet
|
|
Received: from dec3100b.ictp.trieste.it by ITSICTP.BITNET; Sun, 5 Apr 92 14:12 N
|
|
Received: by dec3100b.ictp.trieste.it (5.57/Ultrix3.0-C) id AA27433;
|
|
Sun, 5 Apr 92 14:09:24 +0100
|
|
Date: Sun, 5 Apr 92 14:09:24 +0100
|
|
From: Pietrak Rafal <pietrak@itsictp.bitnet>
|
|
Subject: Re: fd dev
|
|
To: linux-standards@banjo.concert.net, torvalds@cc.helsinki.fi
|
|
Full-Name: Pietrak Rafal
|
|
Message-Id: <9204051309.AA27433@dec3100b.ictp.trieste.it>
|
|
|
|
Tough, I'd prefere having not more then a screenfull in every dir, if
|
|
hierarchical /dev breaks important and none-trivial programs, well,...
|
|
so let there be flat /dev directory. (BTW, I liked UNIX a lot -- and
|
|
Linux in particular -- but here both lost a bit of my hart).
|
|
|
|
As for the block devices naming, I would prefere naming scheme like:
|
|
/dev/[A][N][A][N]..., where S is [a-z] (may be [A-Z], too) strings, and
|
|
N is [0-9] strings, that is numbers.
|
|
|
|
|
|
- Rafal
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 5 21:25:46 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP)
|
|
id <07558-0@banjo.concert.net>; Sun, 5 Apr 1992 21:25:19 -0400
|
|
Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA11790;
|
|
Sun, 5 Apr 92 20:23:24 -0500
|
|
From: asg@sage.cc.purdue.edu (Bruce Varney)
|
|
Message-Id: <9204060123.AA11790@sage.cc.purdue.edu>
|
|
Subject: Re: fd dev
|
|
To: LeBlanc@manchester-computing-centre.ac.uk
|
|
Date: Sun, 5 Apr 92 20:23:23 EST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <05 Apr 92 11:44:47 BST ZLSIIAL@UK.AC.MCC.CMS>; from "LeBlanc@manchester-computing-centre.ac.uk" at Apr 5, 92 11:44 am
|
|
Needs: Your attention
|
|
Organization: Fraternal Order of Red-haired Milkmaids
|
|
|
|
In the unforgettable words of LeBlanc@manchester-computing-centre.ac.uk:
|
|
->
|
|
->
|
|
->Someone has written asking me what is wrong with
|
|
-> /dev/at0
|
|
-> /dev/xt0
|
|
->These names are meaningless to me, and ought to be eliminated.
|
|
|
|
YES!!
|
|
|
|
->
|
|
->Someone else has written to say, with repect to my suggestion
|
|
-> /dev/fd0h3
|
|
-> /dev/fd0q5
|
|
-> /dev/fd1d3
|
|
->that we ought to eliminate the final digit. Unfortunately this
|
|
->means that on some systems /dev/fd0h would be a three inch disk,
|
|
->on others a 5 inch disk, so that the same name would refer to
|
|
->different devices. This in turn would lead to software (eg
|
|
->versions of mtools) that would work on one system but not on
|
|
->another, and for a reason which would be very hard for us net
|
|
->friends to track down (at least the first time). If someone
|
|
->wants to link fd0h to whatever is appropriate for his machine,
|
|
->let him do so, but software should not be distributed which
|
|
->refers to system specific devices.
|
|
|
|
Well, I don't see how your last statement is in agreement with
|
|
everyting else. Software should refer to /dev/fd0, and /dev/fd1. The
|
|
kernel should have the job of using the appropriate driver. You are
|
|
right. Software should NOT refer to system specific devices. /dev/fd0h3
|
|
IS a system specific device. /dev/fd0 is a "generic" device. The name
|
|
is that of the first floppy drive. The kernel will allocate the
|
|
appropriate driver.
|
|
|
|
Bruce
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 5 21:33:08 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP)
|
|
id <07572-0@banjo.concert.net>; Sun, 5 Apr 1992 21:32:41 -0400
|
|
Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA12774;
|
|
Sun, 5 Apr 92 20:30:05 -0500
|
|
From: asg@sage.cc.purdue.edu (Bruce Varney)
|
|
Message-Id: <9204060130.AA12774@sage.cc.purdue.edu>
|
|
Subject: Re: floppy names
|
|
To: spedpr@thor.cardiff.ac.uk (Paul Richards)
|
|
Date: Sun, 5 Apr 92 20:30:04 EST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <24759.9204051553@thor.cf.ac.uk>; from "Paul Richards" at Apr 5, 92 4:53 pm
|
|
Needs: Your attention
|
|
Organization: Fraternal Order of Red-haired Milkmaids
|
|
|
|
In the unforgettable words of Paul Richards:
|
|
->
|
|
->
|
|
->device specific names. Why can't we just have /dev/fpx where x is a
|
|
->number or letter or whatever. There's only one device driver for floppy
|
|
|
|
YES!!!
|
|
|
|
->If we use /dev/fp and I change my drive nothing has to change except the
|
|
->major/minor device number. All software still accesses /dev/fp and the
|
|
->driver takes care of the underlying hardware.
|
|
YES!!!
|
|
|
|
THANK YOU
|
|
At least I know someone out there agrees with me.
|
|
Bruce
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 5 21:57:32 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from kinglear.cs.colorado.edu by banjo.concert.net with SMTP (PP)
|
|
id <07601-0@banjo.concert.net>; Sun, 5 Apr 1992 21:57:06 -0400
|
|
Received: from localhost by kinglear.cs.Colorado.EDU with SMTP
|
|
id AA26775 (5.65c/IDA-1.4.4 for linux-standards@banjo.concert.net);
|
|
Sun, 5 Apr 1992 19:56:55 -0600
|
|
Message-Id: <199204060156.AA26775@kinglear.cs.Colorado.EDU>
|
|
To: asg@sage.cc.purdue.edu (Bruce Varney)
|
|
Cc: linux-standards@banjo.concert.net
|
|
Subject: Re: floppy names
|
|
In-Reply-To: Your message of Sun, 05 Apr 92 20:30:04 -0500. <9204060130.AA12774@sage.cc.purdue.edu>
|
|
Date: Sun, 05 Apr 92 19:56:54 MST
|
|
From: drew@kinglear.cs.Colorado.EDU
|
|
|
|
|
|
--------
|
|
|
|
In the unforgettable words of Paul Richards:
|
|
->
|
|
->
|
|
->device specific names. Why can't we just have /dev/fpx where x is a
|
|
->number or letter or whatever. There's only one device driver for floppy
|
|
|
|
YES!!!
|
|
|
|
->If we use /dev/fp and I change my drive nothing has to change except the
|
|
->major/minor device number. All software still accesses /dev/fp and the
|
|
->driver takes care of the underlying hardware.
|
|
YES!!!
|
|
|
|
THANK YOU
|
|
At least I know someone out there agrees with me.
|
|
Bruce
|
|
|
|
--------
|
|
The problem with this approach is that high density and extra density
|
|
floppies can support two or more denisties per drive. So that these
|
|
are accesable to the user, either
|
|
|
|
1. The kernel must check for disk type.
|
|
2. The user must be able to specify media density, ie with a suffix.
|
|
|
|
Unless you're willing to volunteer for floppy disk driver work,
|
|
or some one else is, the later is what we are stuck with.
|
|
|
|
AIX uses the later approach, with
|
|
/dev/fd[n] the default, high density media, and
|
|
/dev/fd[n] available for low density media.
|
|
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 5 22:19:51 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP)
|
|
id <07625-0@banjo.concert.net>; Sun, 5 Apr 1992 22:19:26 -0400
|
|
Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA22617;
|
|
Sun, 5 Apr 92 21:19:18 -0500
|
|
From: asg@sage.cc.purdue.edu (Bruce Varney)
|
|
Message-Id: <9204060219.AA22617@sage.cc.purdue.edu>
|
|
Subject: Re: floppy names
|
|
To: drew@kinglear.cs.Colorado.EDU
|
|
Date: Sun, 5 Apr 92 21:19:17 EST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <199204060156.AA26775@kinglear.cs.Colorado.EDU>; from "drew@kinglear.cs.Colorado.EDU" at Apr 5, 92 7:56 pm
|
|
Needs: Your attention
|
|
Organization: Fraternal Order of Red-haired Milkmaids
|
|
|
|
->The problem with this approach is that high density and extra density
|
|
->floppies can support two or more denisties per drive. So that these
|
|
->are accesable to the user, either
|
|
->
|
|
->1. The kernel must check for disk type.
|
|
->2. The user must be able to specify media density, ie with a suffix.
|
|
->
|
|
->Unless you're willing to volunteer for floppy disk driver work,
|
|
->or some one else is, the later is what we are stuck with.
|
|
->
|
|
If I had a machine to do it on, I would gladly. Anyone wanna
|
|
make a donation? ;-)
|
|
|
|
Dos doesn't require that you specify which density your disk
|
|
is. So it obviously isn't impossible for the OS to determine it. I am
|
|
not completely familiar with how floppies are layed out, but isn't there
|
|
something that is peculiar to each density? Even Minix has a device
|
|
(/dev/fd0 or something) that will figure out for you what density
|
|
disk is in the drive.
|
|
|
|
Bruce
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Apr 6 04:58:04 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP)
|
|
id <08085-0@banjo.concert.net>; Mon, 6 Apr 1992 04:31:17 -0400
|
|
Received: from jaguar.daimi.aau.dk by daimi.aau.dk with SMTP (5.61++/IDA-1.2.8)
|
|
id AA28639; Mon, 6 Apr 92 10:31:11 +0200
|
|
Received: by jaguar.daimi.aau.dk (5.64/1.34) id AA12440;
|
|
Mon, 6 Apr 92 10:31:09 +0200
|
|
From: poe@daimi.aau.dk
|
|
Message-Id: <9204060831.AA12440@jaguar.daimi.aau.dk>
|
|
Subject: Re: Standard Proposal for Device Naming
|
|
To: abc@banjo.concert.net (Alan B Clegg)
|
|
Date: Mon, 6 Apr 92 10:31:09 MET DST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <9204031756.AA22905@daimi.aau.dk>; from "Alan B Clegg" at Apr 3, 92 12:42 pm
|
|
Organization: DAIMI, Computer Science Department of Aarhus University
|
|
Phone: 86 20 27 11 - 5034
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
> > I think we should stick with the standard density names, ie. d=double,
|
|
> > q=quad and h=high.
|
|
>
|
|
> How many really use all three? Are there still 720k floppy disks around?
|
|
> Why define more than we need? If the need is there, I agree (infact, my
|
|
> original draft [internal use only] had Low, Double, and Quad, until I tried
|
|
> to find a use for all three... LET ME KNOW!
|
|
|
|
I for one would not want the 720k floppies to be discarded. My Amiga can read/
|
|
write these, and not the 1.44MB ones.
|
|
|
|
And I do have some stuff on the Amiga that I might want to use under Linux.
|
|
|
|
- Peter.
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Apr 6 09:17:37 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <09110-0@banjo.concert.net>; Mon, 6 Apr 1992 09:16:46 -0400
|
|
Subject: Proposed Naming Changes (from
|
|
LeBlanc@manchester-computing-centre.ac.uk)
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Mon, 6 Apr 92 9:16:41 EDT
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
In previous mail, LeBlanc@manchester-computing-centre.ac.uk said something like:
|
|
|
|
> /dev/{r}wd[C][N][P]
|
|
>
|
|
> where C is [a-z], N is [0-9], and P is [a-z]. It would be better to
|
|
> have C as [0-9], N as [a-z], and P as [1-xx]. Otherwise we must
|
|
> change or violate the standard when dealing with more than 26
|
|
> partitions. The code in the kernel now deals with up to 60 partitions.
|
|
|
|
This is good, and I agree, but it causes ugly side-effects in the sd code.
|
|
SCSI devices are NUMBERED, so unless we have two different naming schemes
|
|
for scsi and wd type disks, we have a conflict. I agree that support for
|
|
60 partitions is in the kernel, but if we expanded the range of P from [a-z]
|
|
to [a-zA-Z], we double up to 52 and have support for devices up to 1664Meg
|
|
even with the current 32Meg partition maximum size (I assume that will go
|
|
away shortly).
|
|
|
|
I believe that Linus has good ideas on the Floppy drive naming, and I am
|
|
re-writing the document do reflect that, but I still think that we should
|
|
allow support (even if not currently available) for multiple disk controllers
|
|
of any given type. I am about to put a ST-01 into my machine that already
|
|
has an Adaptec 1542 board in it to try out some things in the SCSI code and
|
|
would hate to have to make up my own naming scheme.. 8-)
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Apr 6 10:09:03 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <09376-0@banjo.concert.net>; Mon, 6 Apr 1992 10:08:31 -0400
|
|
Subject: Standard Release (ABC Release of Linux .95a)
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Mon, 6 Apr 92 10:08:27 EDT
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
With the advent of GCC 2.1 and shared libraries, here is a question:
|
|
|
|
Every program in /bin *WILL* be linked static. I have already had to rebuild
|
|
from one "accidental" removal of the shared libraries with shared executables
|
|
in /bin (rm, cp, etc etc).
|
|
|
|
BUT: Should there be a dynamic version of every program that currently lives
|
|
in /bin in /usr/bin? If so, and users have /usr/bin in their path before
|
|
/bin, we allow the use of shared libraries for most programs, and we don't
|
|
blow off a *LOT* of disk space...
|
|
|
|
Just an idea....
|
|
|
|
from the tormented mind of...
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Apr 6 14:36:08 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from twok.ods.com by banjo.concert.net with SMTP (PP)
|
|
id <10960-0@banjo.concert.net>; Mon, 6 Apr 1992 14:35:29 -0400
|
|
Received: by istwok.ods.com id AA22625 (5.65c/IDA-1.3.5);
|
|
Mon, 6 Apr 1992 13:39:00 -0500
|
|
From: David Engel <david@istwok.ods.com>
|
|
Message-Id: <199204061839.AA22625@istwok.ods.com>
|
|
Subject: Re: Standard Release (ABC Release of Linux .95a)
|
|
To: abc@banjo.concert.net (Alan B Clegg)
|
|
Date: Mon, 6 Apr 92 13:38:59 CDT
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <199204061413.AA19542@istwok.ods.com>; from "Alan B Clegg" at Apr 6, 92 10:08 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
> With the advent of GCC 2.1 and shared libraries, here is a question:
|
|
>
|
|
> Every program in /bin *WILL* be linked static. I have already had to rebuild
|
|
> from one "accidental" removal of the shared libraries with shared executables
|
|
> in /bin (rm, cp, etc etc).
|
|
|
|
Well, I plan on putting shared binaries in /bin, but I also plan on putting
|
|
together my own "emergency" root disk with a backup copy of the shared library
|
|
and essential binaries in case I screw up.
|
|
|
|
I don't know the nature of your accidental removal but here a couple things
|
|
I've done to hopefully avoid doing so myself. First, DO NOT put a symlink
|
|
in /lib to the shared library in /usr/shared/lib. Copy it to /lib instead.
|
|
That way you can safely remove /usr/shared when the next update comes around.
|
|
Second, change the mode on your shared libs to 444. Unless you do an rm -f,
|
|
the prompt for comfirmation should make you think twice about deleting it.
|
|
|
|
> BUT: Should there be a dynamic version of every program that currently lives
|
|
> in /bin in /usr/bin? If so, and users have /usr/bin in their path before
|
|
> /bin, we allow the use of shared libraries for most programs, and we don't
|
|
> blow off a *LOT* of disk space...
|
|
|
|
Huh? Wouldn't keeping static versions in /bin and shared versions in /usr/bin
|
|
wast *more* disk space than just static versions in /bin (maybe with symlinks
|
|
in /usr/bin)?
|
|
|
|
-David
|
|
--
|
|
David Engel Optical Data Systems, Inc.
|
|
david@ods.com 1101 E. Arapaho Road
|
|
(214) 234-6400 Richardson, TX 75081
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Apr 6 15:39:23 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <11320-1@banjo.concert.net>; Mon, 6 Apr 1992 15:38:29 -0400
|
|
Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk
|
|
via JANET with NIFTP id <10015-0@sun2.nsfnet-relay.ac.uk>;
|
|
Mon, 6 Apr 1992 14:43:24 +0100
|
|
Message-id: <06 Apr 92 11:44:17 BST ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Mon, 06 Apr 92 11:44:17 BST
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
MyName: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net>
|
|
Subject: device names
|
|
|
|
|
|
I very much like Linus's suggestions, but I have one reservation.
|
|
The use of upper case/lower case to distinguish between 3.5/5.25
|
|
inch drives leaves us with no way of incorporating other sizes
|
|
into the pattern unless their disk geometries match one of these
|
|
two. (In any case, I have already changed my /devs to
|
|
fd0H1440 and fd1h1200 and so forth.)
|
|
|
|
Standardising device names is a pain, since there is not a great
|
|
deal of uniformity among existing systems. It may be tempting
|
|
to adopt names or name formats from elsewhere, which DOES have
|
|
the advantage of not adding to the muddle, but we must be
|
|
cautious about carrying over conventions which may hinder Linux's
|
|
usefulness. I am no Unix beginner, but if it helps beginners,
|
|
I'm for it. I say this because many will be (and already are)
|
|
using Linux who have little or no Unix experience, and we are
|
|
already seeing dozens of questions from them on comp/alt.os.linux
|
|
and elsewhere.
|
|
|
|
I was listening with an open mind (I hope) to the suggestion
|
|
that we abandon device-specific names in favour of generic names,
|
|
e.g., fd0 for all floppies on the first drive. There is a lot
|
|
to be said for this kind of simplicity, which could, for example,
|
|
be created by an installation/configuration script, and I haven't
|
|
completely rejected it. But among the problems I see with it,
|
|
one stands out in particular. It is in fact necessary to have
|
|
different device names for differently formatted floppies in the
|
|
same drive. This is partially because there is no generic way
|
|
of finding out the disk's parameters. Moreover, I and most of
|
|
my users have many disks of many densities, so I can't see this
|
|
problem going away.
|
|
|
|
-- Owen
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Apr 6 15:39:48 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <11320-2@banjo.concert.net>; Mon, 6 Apr 1992 15:38:38 -0400
|
|
Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk
|
|
via JANET with NIFTP id <10600-0@sun2.nsfnet-relay.ac.uk>;
|
|
Mon, 6 Apr 1992 15:08:39 +0100
|
|
Message-id: <06 Apr 92 11:44:17 BST ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Mon, 06 Apr 92 11:44:17 BST
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
MyName: A. V. Le Blanc
|
|
To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net>
|
|
Subject: device names
|
|
|
|
|
|
I very much like Linus's suggestions, but I have one reservation.
|
|
The use of upper case/lower case to distinguish between 3.5/5.25
|
|
inch drives leaves us with no way of incorporating other sizes
|
|
into the pattern unless their disk geometries match one of these
|
|
two. (In any case, I have already changed my /devs to
|
|
fd0H1440 and fd1h1200 and so forth.)
|
|
|
|
Standardising device names is a pain, since there is not a great
|
|
deal of uniformity among existing systems. It may be tempting
|
|
to adopt names or name formats from elsewhere, which DOES have
|
|
the advantage of not adding to the muddle, but we must be
|
|
cautious about carrying over conventions which may hinder Linux's
|
|
usefulness. I am no Unix beginner, but if it helps beginners,
|
|
I'm for it. I say this because many will be (and already are)
|
|
using Linux who have little or no Unix experience, and we are
|
|
already seeing dozens of questions from them on comp/alt.os.linux
|
|
and elsewhere.
|
|
|
|
I was listening with an open mind (I hope) to the suggestion
|
|
that we abandon device-specific names in favour of generic names,
|
|
e.g., fd0 for all floppies on the first drive. There is a lot
|
|
to be said for this kind of simplicity, which could, for example,
|
|
be created by an installation/configuration script, and I haven't
|
|
completely rejected it. But among the problems I see with it,
|
|
one stands out in particular. It is in fact necessary to have
|
|
different device names for differently formatted floppies in the
|
|
same drive. This is partially because there is no generic way
|
|
of finding out the disk's parameters. Moreover, I and most of
|
|
my users have many disks of many densities, so I can't see this
|
|
problem going away.
|
|
|
|
-- Owen
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Apr 7 04:12:37 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <13608-4@banjo.concert.net>; Tue, 7 Apr 1992 03:44:06 -0400
|
|
Received: from thor.cardiff.ac.uk by sun2.nsfnet-relay.ac.uk via JANET
|
|
with NIFTP id <24859-0@sun2.nsfnet-relay.ac.uk>;
|
|
Tue, 7 Apr 1992 03:24:37 +0100
|
|
From: Paul Richards <spedpr@thor.cardiff.ac.uk>
|
|
Message-Id: <6203.9204070226@thor.cf.ac.uk>
|
|
Subject: Re: device names
|
|
To: linux-standards@banjo.concert.net (linux-standards)
|
|
Date: Tue, 7 Apr 92 3:26:00 WET DST
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
In reply to LeBlanc@uk.ac.manchester-computing-centre who said
|
|
> completely rejected it. But among the problems I see with it,
|
|
> one stands out in particular. It is in fact necessary to have
|
|
> different device names for differently formatted floppies in the
|
|
> same drive. This is partially because there is no generic way
|
|
> of finding out the disk's parameters. Moreover, I and most of
|
|
> my users have many disks of many densities, so I can't see this
|
|
> problem going away.
|
|
|
|
It obviously isn't necessary to have different device names since DOS
|
|
deals with this perfectly well and if DOS can do it we can certainly get
|
|
Linux to do it. Of course, someone will have to enlighten us as to how
|
|
DOS does it?
|
|
|
|
Since this is an option when the floppy is formatted is the information
|
|
stored during the format in some way. It seems to me that this is a DOS
|
|
problem in any case. What you're saying is you have lots of DOS floppies
|
|
lying around of different densities. Are we going to base the device
|
|
names on this necessity? Are we really going to continue writing DOS
|
|
format floppies from within Linux? For that matter do we need floppies
|
|
apart from backing up? (Sorry I'm getting a bit ridiculous but these
|
|
points did cross my mind).
|
|
|
|
As an actual proposal. We can keep simple names by makinf the driver try
|
|
the most common density first. If an error occurs then try another one
|
|
and so on. If none of them work then report an error. Not ideal but it
|
|
does show its possible. Someone must know what DOS does?
|
|
|
|
|
|
--
|
|
Paul Richards at Cardiff university, UK.
|
|
|
|
spedpr@uk.ac.cf.thor Internet: spedpr%thor.cf.ac.uk@nsfnet-relay.ac.uk
|
|
UUCP: spedpr@thor.cf.UUCP or ...!uunet!mcsun!ukc!cf!thor!spedpr
|
|
+++
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Apr 7 06:33:02 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from bernina.ethz.ch by banjo.concert.net with SMTP (PP)
|
|
id <14052-0@banjo.concert.net>; Tue, 7 Apr 1992 06:32:39 -0400
|
|
Received: from nessie by bernina.ethz.ch with SMTP inbound
|
|
id <9921-0@bernina.ethz.ch>; Tue, 7 Apr 1992 12:32:18 +0200
|
|
Received: by nessie.cs.id.ethz.ch; Tue, 7 Apr 92 12:32:14 +0200
|
|
Message-Id: <9204071032.AA21232@nessie.cs.id.ethz.ch>
|
|
From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
|
|
Date: Tue, 7 Apr 1992 12:32:13 +0000
|
|
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Re: device names
|
|
|
|
Paul Richards <spedpr@thor.cardiff.ac.uk> writes:
|
|
> It obviously isn't necessary to have different device names since DOS
|
|
> deals with this perfectly well and if DOS can do it we can certainly get
|
|
> Linux to do it. Of course, someone will have to enlighten us as to how
|
|
> DOS does it?
|
|
|
|
Step 1: DOS finds out what density it has to use to read the first track.
|
|
Linux could do that too. Step 2: DOS reads some sectors that describe the
|
|
remaining disk parameters (cylinders, sectors/track, single/double sided,
|
|
etc.). Because Linux does not keep such magic sectors on the disk, it has
|
|
to have other ways to determine those parameters.
|
|
|
|
> Are we really going to continue writing DOS format floppies from
|
|
> within Linux? For that matter do we need floppies apart from backing up?
|
|
|
|
It doesn't matter what we actually do with the disks. The large number of
|
|
different physical formats will always be problem. There are at least four
|
|
common physically different types of floppies (360k, 1.2M, 720k and 1.44M)
|
|
and there are much more confusing formats (i.e. single-sided ones) that DOS'
|
|
FORMAT will happily create.
|
|
|
|
> As an actual proposal. We can keep simple names by makinf the driver try
|
|
> the most common density first. If an error occurs then try another one
|
|
> and so on. If none of them work then report an error. Not ideal but it
|
|
> does show its possible. Someone must know what DOS does?
|
|
|
|
That sounds good. We'd have to have different devices for 3.5" and 5.25"
|
|
disks, the 5.25"/720k format would not be supported and there might be
|
|
problems when new formats become widely used. There might be an ioctl to
|
|
tell the driver about other, 'non-standard' formats. How about this:
|
|
|
|
/dev/fd0.5 /dev/fd1.5 # 5.25", drive A: and B:
|
|
/dev/fd0.3 /dev/fd1.3 # 3.5", drive A: and B:
|
|
|
|
For most practical purposes, this would avoid the need to make non-
|
|
obvious decisions about the floppy format.
|
|
|
|
- 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 linux-standards-request@banjo.concert.net Tue Apr 7 10:56:54 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP)
|
|
id <14697-0@banjo.concert.net>; Tue, 7 Apr 1992 10:56:25 -0400
|
|
Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA27722;
|
|
Tue, 7 Apr 92 09:56:08 -0500
|
|
From: asg@sage.cc.purdue.edu (Bruce Varney)
|
|
Message-Id: <9204071456.AA27722@sage.cc.purdue.edu>
|
|
Subject: Re: device names
|
|
To: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
|
|
Date: Tue, 7 Apr 92 9:56:07 EST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <9204071032.AA21232@nessie.cs.id.ethz.ch>; from "Werner Almesberger" at Apr 7, 92 12:32 pm
|
|
Needs: Your attention
|
|
Organization: Fraternal Order of Red-haired Milkmaids
|
|
|
|
In the unforgettable words of Werner Almesberger:
|
|
->
|
|
->That sounds good. We'd have to have different devices for 3.5" and 5.25"
|
|
->disks, the 5.25"/720k format would not be supported and there might be
|
|
->problems when new formats become widely used. There might be an ioctl to
|
|
->tell the driver about other, 'non-standard' formats. How about this:
|
|
->
|
|
-> /dev/fd0.5 /dev/fd1.5 # 5.25", drive A: and B:
|
|
-> /dev/fd0.3 /dev/fd1.3 # 3.5", drive A: and B:
|
|
->
|
|
|
|
This exactly what I think we should avoid!
|
|
Why do you need /dev/fd0.5 and /dev/fd0.3?? Do you have a 3.5" drive and
|
|
a 5.25" drive that are both assigned as drive 0???? Of course not! The
|
|
driver will know what to do with the drive based on the major an minor
|
|
numbers. The driver DOESN'T CARE WHAT THE NAME IS!! If I had a device named
|
|
/dev/gribble, and assign it the appropriate major and minor to be a
|
|
high deensity 3.5" drive in slot 0, it should work just fine.
|
|
|
|
Bruce
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Apr 7 11:15:42 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
|
|
id <14882-0@banjo.concert.net>; Tue, 7 Apr 1992 11:15:00 -0400
|
|
Received: by sumax.seattleu.edu id AA06113 (5.65a/IDA-1.4.2
|
|
for linux-standards@banjo.concert.net); Tue, 7 Apr 92 08:10:54 -0700
|
|
Date: Tue, 7 Apr 92 08:10:54 -0700
|
|
From: Chuck Boyer <boyer@seattleu.edu>
|
|
Message-Id: <9204071510.AA06113@sumax.seattleu.edu>
|
|
To: almesber@nessie.cs.id.ethz.ch, asg@sage.cc.purdue.edu
|
|
Subject: Re: device names
|
|
Cc: linux-standards@banjo.concert.net
|
|
|
|
At present we need to heat up this discussion, so that it can end
|
|
somewhere.... or just adopt a concensus standard (now) and let
|
|
everybody adjust. Whatever is best for programmers... let's do
|
|
it. I will adjust beginner's guide, etc./other things as necessary.
|
|
boyer@sumax.seattleu.edu
|
|
chuck
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Apr 7 12:26:40 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from bernina.ethz.ch by banjo.concert.net with SMTP (PP)
|
|
id <15086-0@banjo.concert.net>; Tue, 7 Apr 1992 12:26:13 -0400
|
|
Received: from nessie by bernina.ethz.ch with SMTP inbound
|
|
id <17718-0@bernina.ethz.ch>; Tue, 7 Apr 1992 18:26:05 +0200
|
|
Received: by nessie.cs.id.ethz.ch; Tue, 7 Apr 92 18:25:59 +0200
|
|
Message-Id: <9204071625.AA08652@nessie.cs.id.ethz.ch>
|
|
From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
|
|
Date: Tue, 7 Apr 1992 18:25:58 +0000
|
|
In-Reply-To: asg@sage.cc.purdue.edu (Bruce Varney) "Re: device names" (Apr 7, 9:56)
|
|
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
|
|
To: asg@sage.cc.purdue.edu (Bruce Varney)
|
|
Subject: Re: device names
|
|
Cc: linux-standards@banjo.concert.net
|
|
|
|
Bruce Varney writes:
|
|
> Why do you need /dev/fd0.5 and /dev/fd0.3?? Do you have a 3.5" drive and
|
|
> a 5.25" drive that are both assigned as drive 0???? Of course not!
|
|
|
|
Well, I don't like to have more than one name for the same physical
|
|
device (or part of one) myself. But there seems to be no way around
|
|
it :-(
|
|
|
|
> The driver will know what to do with the drive based on the major an minor
|
|
> numbers. The driver DOESN'T CARE WHAT THE NAME IS!!
|
|
|
|
Right, the minor numbers should be different. This is what the driver IMHO
|
|
should do:
|
|
|
|
/dev/fn?.5: - try to set the drive up to use high density disks
|
|
- access the disk
|
|
- if this works, we have a 1.2 MB disk
|
|
- if it doesn't, switch to low density
|
|
- try accessing the disk
|
|
- if it works, it's an old 360k disk
|
|
- if it doesn't, repeat the whole procedure a few
|
|
times, then return an error
|
|
|
|
/dev/fn?.3: the same procedure, but the values are 1.44 MB and
|
|
720k
|
|
|
|
An auto-detection mechanism for all four formats would be more compli-
|
|
cated, slower and unreliable, especially in the presence of media
|
|
errors.
|
|
|
|
Of course it's one of the flaws of this proposal, that it requires
|
|
changes to the floppy driver.
|
|
|
|
- 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 linux-standards-request@banjo.concert.net Tue Apr 7 16:39:44 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from vipunen.hut.fi by banjo.concert.net with SMTP (PP)
|
|
id <15898-0@banjo.concert.net>; Tue, 7 Apr 1992 16:39:13 -0400
|
|
Received: by vipunen.hut.fi (5.65c/7.0/S-TeKoLa) id AA89584;
|
|
Tue, 7 Apr 1992 20:38:41 GMT
|
|
Date: Tue, 7 Apr 1992 20:38:41 GMT
|
|
From: Pauli R{m| <ramo@vipunen.hut.fi>
|
|
Message-Id: <199204072038.AA89584@vipunen.hut.fi>
|
|
To: almesber@nessie.cs.id.ethz.ch, asg@sage.cc.purdue.edu
|
|
Subject: Re: device names
|
|
Cc: linux-standards@banjo.concert.net
|
|
|
|
Why can't the diskette drive type just be read from the cmos at bootup
|
|
like the info about hard disks? That way there should be no need to
|
|
use multiple device names (and minor numbers) for different types of
|
|
drives. The auto-detection would also be much easier, because the kernel
|
|
had to check for at most 2 densities. The density could of course be
|
|
checked by trying to read sector 10 from the first track (at least in
|
|
the case of 360k/1.2M and 720k/1.44M diskettes).
|
|
|
|
Pauli
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Apr 7 16:54:06 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from golem.wcc.govt.nz by banjo.concert.net with SMTP (PP)
|
|
id <15943-0@banjo.concert.net>; Tue, 7 Apr 1992 16:53:23 -0400
|
|
Received: from csc.wcc.govt.nz by golem.wcc.govt.nz id <AA28924-5.65a+VUW/4.0>;
|
|
Wed, 8 Apr 92 07:53:36 +1200
|
|
Received: by csc.wcc.govt.nz (MX V3.0) id 2944; Wed, 08 Apr 1992 08:55:19 EDT
|
|
Sender: hamilton <hamilton@csc.wcc.govt.nz>
|
|
Date: Wed, 08 Apr 1992 08:55:15 EDT
|
|
From: hamilton@csc.wcc.govt.nz
|
|
To: linux-standards@banjo.concert.net
|
|
Cc: hamilton@csc.wcc.govt.nz
|
|
Message-Id: <00958CA2.83B11960.2944@csc.wcc.govt.nz>
|
|
Subject: device names
|
|
|
|
|
|
>It obviously isn't necessary to have different device names since DOS
|
|
>deals with this perfectly well and if DOS can do it we can certainly get
|
|
--
|
|
>Linux to do it. Of course, someone will have to enlighten us as to how
|
|
>DOS does it?
|
|
|
|
This person called "we" is sure gonna being doing heaps for linux :)
|
|
|
|
I think someone has already raised the following points, but I think I
|
|
would like to emphisize them more. Has someone actually taken up the
|
|
task of working on smarter drivers (in particular the floppy). It
|
|
doesn't seem like a very exciting task: the current ones do an
|
|
adequate job. Perhaps the standard we need the soonest is one that
|
|
copes with the present, and actively being worked on, situation.
|
|
Maybe we could agree to get this out of the way first.
|
|
|
|
Sounds like we need a standard for what linux can do now (or soon),
|
|
and a standard for what we want it to do in the longer term future.
|
|
Maybe we should have a "prefered directions standard", ie a statement
|
|
of where we'd like to be in a ideal situation.
|
|
|
|
I've kind of lost track of the devices discussion, anyone got a summary
|
|
of the most promising alternatives?
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Apr 7 18:05:21 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP)
|
|
id <16262-0@banjo.concert.net>; Tue, 7 Apr 1992 18:04:52 -0400
|
|
Received: from amcl14.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA22755;
|
|
Tue, 7 Apr 92 17:04:44 CDT
|
|
Date: Tue, 7 Apr 92 17:04:44 CDT
|
|
From: johnsonm@stolaf.edu (Michael K. Johnson)
|
|
Message-Id: <9204072204.AA22755@stolaf.edu>
|
|
Received: by amcl14.math.stolaf.edu (4.1/SMI-4.1) id AA00927;
|
|
Tue, 7 Apr 92 17:04:44 CDT
|
|
To: linux-standards@banjo.concert.net
|
|
In-Reply-To: Bruce Varney's message of Tue, 7 Apr 92 9:56:07 EST <9204071456.AA27722@sage.cc.purdue.edu>
|
|
Subject: device names
|
|
|
|
From: asg@sage.cc.purdue.edu (Bruce Varney)
|
|
|
|
This exactly what I think we should avoid!
|
|
Why do you need /dev/fd0.5 and /dev/fd0.3?? Do you have a 3.5" drive and
|
|
a 5.25" drive that are both assigned as drive 0????
|
|
|
|
Well, I agree with you wholeheartedly, but I couldn't resist pointing
|
|
out that canon, I think, (well, someone) has come out with a dual
|
|
drive which I have heard can be configured as one drive name that
|
|
handles 3.5 & 5.25. But there are other ways of dealing with such a
|
|
problem. BTW, if anyone knows these drives better, please correct me
|
|
-- all I've heard are rumors and seen pretty (ugly) pictures. ;-)
|
|
|
|
Of course not! The
|
|
driver will know what to do with the drive based on the major an minor
|
|
numbers. The driver DOESN'T CARE WHAT THE NAME IS!! If I had a device named
|
|
/dev/gribble, and assign it the appropriate major and minor to be a
|
|
high deensity 3.5" drive in slot 0, it should work just fine.
|
|
|
|
Bruce
|
|
|
|
Not trying to break your point, though...
|
|
|
|
michaelkjohnson
|
|
johnsonm@stolaf.edu
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 8 08:51:19 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun3.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <18849-0@banjo.concert.net>; Wed, 8 Apr 1992 08:50:45 -0400
|
|
Via: sun3.nsfnet-relay.ac.uk; Wed, 8 Apr 1992 14:24:53 +0100
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa02687;
|
|
8 Apr 92 14:29 BST
|
|
Date: Wed, 08 Apr 92 14:11:32 +0100
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: malloc standard behaviour.
|
|
|
|
Well, let's go away for a bit from the /dev discussion :-)
|
|
I agree with everything abc will say, after all is not a big deal :-)
|
|
( I still like the idea of a device name with some meaning... )
|
|
|
|
Anyway. Iesterday I was recompiling Cron... Not much problems
|
|
Quite straightforward :-) BUT, just one problem
|
|
|
|
During the testing cron went on allocating memory and more memory
|
|
and using the said memory :-) I was watching the free space going down
|
|
and down and wondering what was going to happen. I was feeling safe
|
|
since cron was run interactively.
|
|
|
|
At some point the memory ( even the virtual one ) finished. I was waiting
|
|
for cron to die...... Wait,,,, Wait...., Wait... 10 minutes :-)
|
|
Cron don't die.... In the meantime the machine is almost hung
|
|
It is not dead, it is alive, it is just so slow that you can't use it
|
|
and NO command can be run ( no memory available ).
|
|
|
|
You may wonder why this is in the standard list :-)
|
|
Well it has to do with how malloc is done.
|
|
|
|
As it is now malloc is like mach like it. You can malloc everything you
|
|
like you just run in trouble when you try to use it...
|
|
|
|
I don't like it, or better I would like to be able to choose between
|
|
this and the other possible behaviour ( the standard one ).
|
|
|
|
You may ask why I don't like it...
|
|
Suppose that my dear cron malloc some memory... malloc says OK. The
|
|
program run happly. At some point malloc try to use the memory.
|
|
What happens ? Cron die ? cron hung ? machine hung ?
|
|
|
|
Suppose one "not friendly" user want to give me trouble ....
|
|
Very easy, malloc (BIGNUM); for (x=0;x<BIG<x++) ptr[x]=0;
|
|
and trap the memfault signal.....
|
|
|
|
Not that this problem goes away with the old style malloc. But it probably
|
|
get less worse. I had to deal with this stuff in a 3B2 and if you
|
|
make ps remaining in swap with the stiky bit you can find out who is
|
|
causing problems and "shut him" :-)
|
|
|
|
What I would like is:
|
|
A malloc that optionally control if the requested memory is available
|
|
and alloc for me all that memory.
|
|
A mach style malloc that don't trash the machine when the requested page
|
|
is not available...
|
|
|
|
The point is. Are most of you happy with the current implementation of
|
|
malloc ? ( after having considered the possible problems )
|
|
|
|
Damiano
|
|
|
|
I will try to start looking for a solution if some competent person
|
|
tell me that is reasonably simple to do.
|
|
( Not that I have much time.... but I will try )
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 8 11:47:53 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from TSX-11.MIT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <20273-0@banjo.concert.net>; Wed, 8 Apr 1992 11:46:56 -0400
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA14376;
|
|
Wed, 8 Apr 92 12:24:08 -0400
|
|
Date: Wed, 8 Apr 92 12:24:08 -0400
|
|
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
|
|
Message-Id: <9204081624.AA14376@tsx-11.MIT.EDU>
|
|
To: Damiano Bolla <db1@ukc.ac.uk>
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: Damiano Bolla's message of Wed, 08 Apr 92 14:11:32 +0100, <9204081331.AA06430@Athena.MIT.EDU>
|
|
Subject: Re: malloc standard behaviour.
|
|
Reply-To: tytso@athena.mit.edu
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
Date: Wed, 08 Apr 92 14:11:32 +0100
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
|
|
Suppose one "not friendly" user want to give me trouble ....
|
|
Very easy, malloc (BIGNUM); for (x=0;x<BIG<x++) ptr[x]=0;
|
|
and trap the memfault signal.....
|
|
|
|
What I would like is:
|
|
A malloc that optionally control if the requested memory is available
|
|
and alloc for me all that memory.
|
|
A mach style malloc that don't trash the machine when the requested page
|
|
is not available...
|
|
|
|
The point is. Are most of you happy with the current implementation of
|
|
malloc ? ( after having considered the possible problems )
|
|
|
|
This really isn't a malloc problem; malloc is just a bit of user library
|
|
code that is calling sbrk(). The real problem here is that the VM isn't
|
|
really doing any bounds checking. The sbrk() call never returns an
|
|
error, and if you reference a non-existent page, the VM will happily
|
|
create a zero-filled page for you. That's the real problem.
|
|
|
|
There are two tacks we can take to solve this problem. The first is to
|
|
add BSD-style resource limits to the kernel. Actually, the getrlimit()
|
|
and setrlimit() calls are already in the kernel (I added them back when
|
|
I thought I was going to have to work on making core dumps work :-) The
|
|
kernel just needs to enforce the limits in the task_struct structure.
|
|
Look at sys/resource.h for the relevent data structures.
|
|
|
|
The second tack is to improve the VM so that it will complain if you try
|
|
to reference a page that is between the end of your data segment and
|
|
your stack area. This is not related to malloc() per se, except that
|
|
fixing this will fix similar problems when a program (such as compress)
|
|
goes wild and starts referencing a lot of non-existent pages.
|
|
|
|
- Ted
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 8 12:24:55 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun3.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <20575-0@banjo.concert.net>; Wed, 8 Apr 1992 12:24:25 -0400
|
|
Via: sun3.nsfnet-relay.ac.uk; Wed, 8 Apr 1992 17:58:33 +0100
|
|
Message-id: <08 Apr 92 17:20:00 BST ZLSIIAL@UK.AC.MCC.CMS>
|
|
Date: Wed, 08 Apr 92 17:20:00 BST
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
MyName: A. V. Le Blanc
|
|
To: linux-standards <linux-standards@banjo.concert.net>
|
|
Subject: static bin
|
|
|
|
|
|
I'm not sure why you need to have eveything in /bin statically
|
|
linked. I've moved the lib92.xx.xx on my systems to lib
|
|
instead of having a pointer there; this eliminates (in practice)
|
|
the likelihood that I'll delete some gcc2 directory by accident.
|
|
When space is tight -- and on my system it's like swimming in a
|
|
bathtub, every little bit helps. You could always distribute
|
|
statically linked versions of everything for the cautious.
|
|
|
|
-- Owen
|
|
LeBlanc@mcc.ac.uk
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 8 14:00:15 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from banjo.concert.net by banjo.concert.net
|
|
id <00308-0@banjo.concert.net>; Wed, 8 Apr 1992 13:59:54 -0400
|
|
Subject: Unfortunate, but true....
|
|
To: linux-standards@banjo.concert.net
|
|
Date: Wed, 8 Apr 92 13:59:51 EDT
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
From: Alan B Clegg <abc@banjo.concert.net>
|
|
Sender: abc@banjo.concert.net
|
|
|
|
I will *NOT* be producing the "ABC Release of Linux .95a" before I go on
|
|
vacation. I am currently over-whelmed by work, and won't have free-time
|
|
before leaving on Saturday morning.
|
|
|
|
In the off-chance that I do get some time, it will be devoted to getting
|
|
my scsi disk back working again, as that is where the sources that I have
|
|
so-far compiled are living... 8-(
|
|
|
|
-abc
|
|
--
|
|
abc@concert.net Alan Clegg - Network Programmer
|
|
KD4JML (just my luck!) MCNC -- Center for Communications
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 8 18:42:43 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP)
|
|
id <01564-0@banjo.concert.net>; Wed, 8 Apr 1992 18:42:28 -0400
|
|
Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA29068;
|
|
Wed, 8 Apr 92 17:11:40 -0500
|
|
From: asg@sage.cc.purdue.edu (Bruce Varney)
|
|
Message-Id: <9204082211.AA29068@sage.cc.purdue.edu>
|
|
Subject: Re: device names
|
|
To: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
|
|
Date: Wed, 8 Apr 92 17:11:39 EST
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: <9204071625.AA08652@nessie.cs.id.ethz.ch>; from "Werner Almesberger" at Apr 7, 92 6:25 pm
|
|
Needs: Your attention
|
|
Organization: Fraternal Order of Red-haired Milkmaids
|
|
|
|
In the unforgettable words of Werner Almesberger:
|
|
->
|
|
->> The driver will know what to do with the drive based on the major an minor
|
|
->> numbers. The driver DOESN'T CARE WHAT THE NAME IS!!
|
|
->
|
|
->Right, the minor numbers should be different. This is what the driver IMHO
|
|
->should do:
|
|
->
|
|
->An auto-detection mechanism for all four formats would be more compli-
|
|
->cated, slower and unreliable, especially in the presence of media
|
|
->errors.
|
|
->
|
|
|
|
But you wouldn't need an autodetection mechanism for all four
|
|
formats. The major and minor numbers of the device would tell it what
|
|
formats to try. Why do you want to base a driver, located in the kernel
|
|
on device names instead of numbers???
|
|
|
|
Bruce
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 8 19:46:21 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from bernina.ethz.ch by banjo.concert.net with SMTP (PP)
|
|
id <01803-0@banjo.concert.net>; Wed, 8 Apr 1992 19:46:07 -0400
|
|
Received: from nessie by bernina.ethz.ch with SMTP inbound
|
|
id <25581-0@bernina.ethz.ch>; Thu, 9 Apr 1992 01:45:55 +0200
|
|
Received: by nessie.cs.id.ethz.ch; Thu, 9 Apr 92 01:45:49 +0200
|
|
Message-Id: <9204082345.AA20982@nessie.cs.id.ethz.ch>
|
|
From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
|
|
Date: Thu, 9 Apr 1992 01:45:48 +0000
|
|
In-Reply-To: asg@sage.cc.purdue.edu (Bruce Varney) "Re: device names" (Apr 8, 17:11)
|
|
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
|
|
To: asg@sage.cc.purdue.edu (Bruce Varney)
|
|
Subject: Re: device names
|
|
Cc: linux-standards@banjo.concert.net
|
|
|
|
asg@sage.cc.purdue.edu (Bruce Varney) writes:
|
|
> But you wouldn't need an autodetection mechanism for all four formats.
|
|
> The major and minor numbers of the device would tell it what formats to try.
|
|
|
|
That's exactly my point ;-)
|
|
|
|
> Why do you want to base a driver, located in the kernel on device names
|
|
> instead of numbers???
|
|
|
|
I guess that might be difficult ;-) No, seriously, I probably didn't
|
|
make that clear enough: /dev/fd0.3 etc. should of course have different
|
|
minor/major numbers too.
|
|
|
|
What I'm proposing is simply a compromise between a complex detection
|
|
mechanism a la DOS and distinct devices for each supported format.
|
|
|
|
Maybe we should move this discussion to comp.os.linux, because it's more
|
|
about driver design than about standards.
|
|
|
|
- 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 linux-standards-request@banjo.concert.net Wed Apr 8 23:29:49 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from TSX-11.MIT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <02267-0@banjo.concert.net>; Wed, 8 Apr 1992 23:29:33 -0400
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA18231;
|
|
Wed, 8 Apr 92 23:27:12 -0400
|
|
Date: Wed, 8 Apr 92 23:27:12 -0400
|
|
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
|
|
Message-Id: <9204090327.AA18231@tsx-11.MIT.EDU>
|
|
To: LeBlanc@manchester-computing-centre.ac.uk
|
|
Cc: linux-standards <linux-standards@banjo.concert.net>
|
|
In-Reply-To: LeBlanc@manchester-computing-centre.ac.uk's message of Wed, 08 Apr 92 17:20:00 BST, <08 Apr 92 17:20:00 BST ZLSIIAL@UK.AC.MCC.CMS>
|
|
Subject: Re: static bin
|
|
Reply-To: tytso@athena.mit.edu
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
Date: Wed, 08 Apr 92 17:20:00 BST
|
|
From: LeBlanc@manchester-computing-centre.ac.uk
|
|
Myname: A. V. Le Blanc
|
|
|
|
I'm not sure why you need to have eveything in /bin statically
|
|
linked. I've moved the lib92.xx.xx on my systems to lib
|
|
instead of having a pointer there; this eliminates (in practice)
|
|
the likelihood that I'll delete some gcc2 directory by accident.
|
|
|
|
No, you don't need *everything* in /bin to be statically linked.
|
|
However, it is wise to make /bin/ls, /bin/cp, /bin/mv, and /bin/sh be
|
|
statically linked. That way, you do surgery on the shared library
|
|
without losing big-time. Otherwise, you could replace the library with
|
|
a new one that turns out to bad, and you would be up the creek without a
|
|
paddle. It's not you might delete them by accident, but that you might
|
|
replace them with a new version that turns out to be built wrong.
|
|
|
|
This tends to be relatively common in SunOS, when you are ripping out
|
|
YP, and replacing it with DNS --- if you screw up while doing surgery on
|
|
libc.a, only /bin/mv on SunOS is statically linked. So you what you
|
|
have to do is to copy the new libc.a to libc.a.new, move the old libc
|
|
out of the way (thus breaking all other programs except for /bin/mv) and
|
|
then move the new libc.a into place. If you're lucky, things start
|
|
working again. If you're not lucky, everything's broken except for
|
|
/bin/mv, which you use to move the old libc.a back into place. But that
|
|
gets really hairy. It would be nice to have a few more tools (like ls
|
|
and cp) when you're doing surgery on shared library files.
|
|
|
|
- Ted
|
|
|
|
From linux-standards-request@banjo.concert.net Mon Apr 13 06:40:52 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from sun3.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
|
|
id <12687-0@banjo.concert.net>; Mon, 13 Apr 1992 06:40:38 -0400
|
|
Via: sun3.nsfnet-relay.ac.uk; Mon, 13 Apr 1992 11:37:12 +0100
|
|
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa04166;
|
|
13 Apr 92 11:39 BST
|
|
Date: Mon, 13 Apr 92 11:35:03 +0100
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
To: linux-standards@banjo.concert.net
|
|
Subject: Please Please Plase :-)
|
|
|
|
Can ve have a new subtree for linux that has gcc2 + the stuff
|
|
compiled with gcc2 ( They need the libarary )
|
|
SOmething like
|
|
linux1.0/INSTALL
|
|
linux1.0/bin
|
|
linux1.0/lib
|
|
linux1.0/usr/src
|
|
linux1.0/usr/bin
|
|
linux1.0/etc
|
|
linux1.0/......
|
|
|
|
It will save :
|
|
Time for the FTP admin ( It is easier to handle )
|
|
Net bandwidth ( I am not downloading the new tree if I don't have gcc2 )
|
|
Time for the users ( Gosh, is this program new or old ? )
|
|
|
|
Will anybody do it ?
|
|
|
|
Damiano
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Apr 14 01:06:34 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from TSX-11.MIT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <14110-0@banjo.concert.net>; Tue, 14 Apr 1992 01:06:20 -0400
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA17914;
|
|
Tue, 14 Apr 92 01:05:31 -0400
|
|
Date: Tue, 14 Apr 92 01:05:31 -0400
|
|
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
|
|
Message-Id: <9204140505.AA17914@tsx-11.MIT.EDU>
|
|
To: Damiano Bolla <db1@ukc.ac.uk>
|
|
Cc: linux-standards@banjo.concert.net
|
|
In-Reply-To: Damiano Bolla's message of Mon, 13 Apr 92 11:35:03 +0100, <9204131041.AA20894@Athena.MIT.EDU>
|
|
Subject: Re: Please Please Plase :-)
|
|
Reply-To: tytso@athena.mit.edu
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
Date: Mon, 13 Apr 92 11:35:03 +0100
|
|
From: Damiano Bolla <db1@ukc.ac.uk>
|
|
|
|
Can ve have a new subtree for linux that has gcc2 + the stuff
|
|
compiled with gcc2 ( They need the libarary )
|
|
|
|
SOmething like
|
|
linux1.0/......
|
|
|
|
For right now, I would much rather request that people who are uploading
|
|
binaries to FTP sites *not* upload dynamically linked programs. That
|
|
means they need to compile programs with the -static flag. Even after
|
|
Linux 1.0 comes out (which it hasn't, yet), the dependency of which
|
|
shared library you need to use in order to win may still make it not
|
|
worthwhile to archive shared-library executables.
|
|
|
|
If the ABC release takes off enough so that everybody is using the same
|
|
shared libraries, then perhaps it will work; I hope that is the case,
|
|
but I don't want to count on it.
|
|
|
|
In the mean time, please only upload statically linked programs to
|
|
TSX-11. I think it will make people's lives much easier.
|
|
|
|
- Ted
|
|
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Tue Apr 14 10:31:54 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from twok.ods.com by banjo.concert.net with SMTP (PP)
|
|
id <14572-0@banjo.concert.net>; Tue, 14 Apr 1992 10:31:35 -0400
|
|
Received: by istwok.ods.com id AA14155 (5.65c/IDA-1.3.5);
|
|
Tue, 14 Apr 1992 09:27:53 -0500
|
|
From: David Engel <david@istwok.ods.com>
|
|
Message-Id: <199204141427.AA14155@istwok.ods.com>
|
|
Subject: Re: Please Please Plase :-)
|
|
To: tytso@athena.mit.edu
|
|
Date: Tue, 14 Apr 92 9:27:51 CDT
|
|
Cc: db1@ukc.ac.uk, linux-standards@banjo.concert.net
|
|
In-Reply-To: <9204140505.AA17914@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Apr 14, 92 1:05 am
|
|
X-Mailer: ELM [version 2.3 PL11]
|
|
|
|
> For right now, I would much rather request that people who are uploading
|
|
> binaries to FTP sites *not* upload dynamically linked programs. That
|
|
> means they need to compile programs with the -static flag. Even after
|
|
|
|
What about uploading "ready-to-be-linked" objects like we did with GCC 2.1
|
|
in 2.1shared-A.tar.Z? This way, everybody gets to decide for themselves
|
|
whether they want to use the shared libraries or not. It is also nice for
|
|
handling library bugs because you can usually just relink when a new library
|
|
comes out.
|
|
|
|
David
|
|
--
|
|
David Engel Optical Data Systems, Inc.
|
|
david@ods.com 1101 E. Arapaho Road
|
|
(214) 234-6400 Richardson, TX 75081
|
|
|
|
From linux-standards-request@banjo.concert.net Wed Apr 15 14:29:15 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from TSX-11.MIT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <16652-0@banjo.concert.net>; Wed, 15 Apr 1992 14:29:02 -0400
|
|
Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA29122;
|
|
Wed, 15 Apr 92 14:28:54 -0400
|
|
Date: Wed, 15 Apr 92 14:28:54 -0400
|
|
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
|
|
Message-Id: <9204151828.AA29122@tsx-11.MIT.EDU>
|
|
To: David Engel <david@istwok.ods.com>
|
|
Cc: db1@ukc.ac.uk, linux-standards@banjo.concert.net
|
|
In-Reply-To: David Engel's message of Tue, 14 Apr 92 9:27:51 CDT, <199204141427.AA14155@istwok.ods.com>
|
|
Subject: Re: Please Please Plase :-)
|
|
Reply-To: tytso@athena.mit.edu
|
|
Address: 1 Amherst St., Cambridge, MA 02139
|
|
Phone: (617) 253-8091
|
|
|
|
From: David Engel <david@istwok.ods.com>
|
|
Date: Tue, 14 Apr 92 9:27:51 CDT
|
|
|
|
What about uploading "ready-to-be-linked" objects like we did with GCC 2.1
|
|
in 2.1shared-A.tar.Z? This way, everybody gets to decide for themselves
|
|
whether they want to use the shared libraries or not. It is also nice for
|
|
handling library bugs because you can usually just relink when a new library
|
|
comes out.
|
|
|
|
It is true that the "ready-to-be-linked" objects have the advantage that
|
|
you can relink when a new library comes out. However.... this assumes
|
|
that people keep the .o files around --- which will either consume disk
|
|
space or time and bother to back them up to floppies.
|
|
|
|
Also, I'm not sure how convenient "ready-to-be-linked" objects really
|
|
are. I suspect that people who are willing to go through the bother of
|
|
linking .o files are probably also willing to untar a source
|
|
distribution and compile it themselves. True, a source distribution
|
|
takes more time to download, and takes a few extra seconds (but if you
|
|
have a fast 386/486 it is *only* few extra seconds, or minutes at most),
|
|
but I'm not convinced that there's enough of a difference between a
|
|
source distribution and .o files so that it is worthwhile to do both.
|
|
|
|
Binaries, on the other hand, you just download and go. True, you have
|
|
to worry library bugs, and whether or not you have the right shared
|
|
library if you're using such beasts, but there are ways we can make that
|
|
easier. For example, we could require that uploaded programs use only
|
|
statically linked libraries, or we could require that uploaded programs
|
|
be linked against some standard shared libc.a --- which wouldn't change
|
|
often. (When it did change, people would have to keep the old shared libc
|
|
around until all of their binaries stopped using it; this means we want
|
|
to minimize the number of times the libc has to change.)
|
|
|
|
So I'm not convinced that .o files are necessarily the right way to go.
|
|
I'm willing to be conviced, of course, but right now I think uploading
|
|
only statically linked binaries (and maybe shifting over to binaries
|
|
linked with a standard shared libc, once it stablizes) is the wisest
|
|
course. People who feel otherwise are welcome to send me mail. :-)
|
|
|
|
- Ted
|
|
|
|
|
|
|
|
|
|
|
|
From linux-standards-request@banjo.concert.net Sun Apr 26 19:04:39 1992
|
|
Return-Path: <linux-standards-request@banjo.concert.net>
|
|
Received: from JARTHUR.CLAREMONT.EDU by banjo.concert.net with SMTP (PP)
|
|
id <15742-0@banjo.concert.net>; Sun, 26 Apr 1992 19:04:16 -0400
|
|
Date: Sun, 26 Apr 92 16:03:11 PDT
|
|
From: "Jim Winstead Jr." <jwinstea@jarthur.Claremont.EDU>
|
|
To: Adam Thompson <umthom61@ccu.umanitoba.ca>
|
|
cc: torvalds@cc.helsinki.fi, linux-standards@banjo.concert.net,
|
|
ftp-linux@tsx-11.mit.edu, arl@cs.hut.fi
|
|
Subject: Re: Version numbering (was Re: pre-0.96)
|
|
|
|
|
|
In comp.os.linux you write:
|
|
>>have letter prefixes (0.96a, 0.96b), and the root image will be
|
|
> ^^^^^^^^^^^^^^
|
|
>funny ... I could have *sworn* those were *suffixes* :-)
|
|
|
|
Oops. That must be why I'm not an English major.
|
|
|
|
>>updated with a minor number (0.96.1, 0.96.2, etc). This will let
|
|
>>Linus and I keep slightly different schedules, and hopefully eliminate
|
|
>>some confusion. (Where's the 0.95c++ root image?)
|
|
>
|
|
>Eliminate confusion... ? OHHHHHH shit. Let me see, I've got my
|
|
>0.96f kernel, (let's say) and I therefore need a root disk... hmm!
|
|
>neato, the root disk that matches is 0.95a ... sure ... Oh well.
|
|
>As long as everybody -knows- what goes with what...
|
|
|
|
I think you missed my point. As of 0.96, there will be two images -
|
|
boot-0.96 and root-0.96. After this, the two images will proceed like
|
|
this:
|
|
|
|
for the boot disk, or kernel, which Linus deals with, it will
|
|
be numbered as 0.96a, 0.96b, 0.96c, 0.96d, etc, hopefully
|
|
avoiding all the silly stuff with +'s.
|
|
|
|
for the root disk, which I deal with, it will be identified
|
|
as 0.96.1, 0.96.2, 0.96.3, etc.
|
|
|
|
Now, here's the real beauty of it: If there is a change in
|
|
the kernel that _requires_ changes to the root disk (or, less likely,
|
|
the other way around), or if Linus and I (and others) decide enough
|
|
progress has been made, the 'major' version number will be incremented
|
|
to 0.97, or whatever.
|
|
|
|
The main point is: All root and boot images with 0.96 roots should be
|
|
compatible. This also allows Linus and I to keep completely different
|
|
schedules between major releases, which until now has really been
|
|
impossible.
|
|
|
|
This has been cc'ed to Linus, the Linux-Standards list, and a couple
|
|
of FTP site managers for their comment.
|
|
|