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 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: 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 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: 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: 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 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: 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: 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 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: 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 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: 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: 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 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: 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 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: 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_ N1DPU MIT Student Information Processing Board Cygnus Support From linux Thu Feb 6 14:52:21 1992 Return-Path: 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 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: 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 ; 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 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: 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: 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: 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 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: 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 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: 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 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: 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: 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: 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: 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 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: 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: 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 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: 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: 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: 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: 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: 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: 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 ; Thu, 13 Feb 92 10:42 CST Message-Id: 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: 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: ; 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: 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 ; Thu, 13 Feb 92 13:25 CST Message-Id: 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: 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: 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: 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: 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 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: 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: 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: 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: 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 ; Fri, 14 Feb 92 21:50 CST Message-Id: 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: 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, 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: 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 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: 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 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: ; 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: 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 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: 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 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: 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: 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_ MIT Student Information Processing Board From linux-standards-request@concert.net Thu Feb 20 02:53:38 1992 Return-Path: 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: 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: 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 ; Thu, 20 Feb 92 09:49 CST Message-Id: 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_ 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: 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 ; Thu, 20 Feb 92 09:54 CST Message-Id: 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: 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 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: 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: ; from "David W. Summers" at Feb 20, 92 9:49 am X-Mailer: ELM [version 2.3 PL11] From: Alan B Clegg 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: 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: ; from "David W. Summers" at Feb 20, 92 9:54 am X-Mailer: ELM [version 2.3 PL11] From: Alan B Clegg 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: 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 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: 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, 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: 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_ 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: 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: 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: 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" 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: ; 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: 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: 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 ; 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 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: 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: 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: 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: 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 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: 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: 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: 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: 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 ; Tue, 3 Mar 92 23:28 PST Message-Id: 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, 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 for memory - struct psmeter {...} and for tasks - struct iometer {...} and 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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: 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: 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 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: 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 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: 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 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: 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 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: 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 ); Wed, 11 Mar 1992 15:41:38 -0600 Return-Path: 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: 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: 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." 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: 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." 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: 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." 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: 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 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: 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 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: 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: ; from "Damiano Bolla" at Mar 24, 92 9:16 am X-Mailer: ELM [version 2.3 PL11] From: Alan B Clegg 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: 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 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: 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 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: 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: 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 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: 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 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: 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 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: 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: 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." To: Alan B Clegg 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: 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 "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: 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: 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 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: 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: 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 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 #include #include #include #include #include #include /* Definition of video modes */ #include /* 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 #include #include #include #include #include #include /* 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 0) && (i 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 #include #include #include 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 . * 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 #include #include #include #include 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&^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%`=`(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/&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@O`(QE#XQR'($&EK7(->R(_J`[Z'S!#^K?JW$T M.[_S%0J<*T@3"P'1@!.--/XD4P<^1.,RQ]'1%/^[#U<"P#8!_X1R7"8%;#2( M-``0'`$=.]"& 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!=0J0]'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>,,RC\L`%`^^G$4 M]2@`+@!0`S\FP@/A*``C##".`CC@`Q,M@2X`ZD=/+L(!G$#`.%S@"`-`LV4V M8`$`BF$`3R"`$=J8P39L\`\/:`(!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!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(,'#:##&Q20M34B(`.).`!%QXBA'608P;)"$*LAZT/7W=W`!:>QB*"$8UT3"`:J+B7 M,M81`%CC>@6[/H&S=2%L8J^#'!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`"]-`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``MF0J$>2B`!UB`0& ML#<&<(GWDPJ'SI(@!6L#-]80PM M<(<1:!;(T#P:V#P%``ZW*!?VT(>#@'3?:`"[<0"G]`_I@`@`P(<&$!L&``A, M8``@L`[M`(\&$``&Y`^`<`+[,(X,4`$`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"Y84PT`!XJ9$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%X$D)5; M>8W@D(U?V8W^,%'^(@PIV8G"DPA'0`#+A1E/8``(D(^O&9O^:9["`P@OFHRZ MH:(0",>BRA:0<& M9`"*<`0E*15D<`&8F35D<%X&P*$C%* M8`"+,`]WJ9$KN@XJ8*.?^0<$0)IT`*F^FIIU@`&7FJGHD`"<>A7+E0"I2B;D M4JA,VA30N`+_,)(&0`(#`$B*N9N]"9C`::;$>9@120[.+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`P3,]0]8@'1N(K4H,0C' M,(]HT+L)@!+K``S$2R;K@`O$:SGK``NSNP5UL`24`<$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`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`<+&`D`-23=78L`X)H`A+/18E0"8M*L79S,M)G`BF MR!=9_7EU4*]J/0#&.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?%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;@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:\SRL`1&%T]``O,, MZ2`-M"7.9/O'_5L'AK`2,BQFUOD(`#)#!Y.$7*2##\`J+$`'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$$R9CS]P<.@CPEVBK-@N\($@@R[X M("/L#72`BB((^K$#'LD.\`/9LA$`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`BER10!_;'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/YECP4,TH M*'5C*:X>.9AN$RJ;7- M0>)B1YC#E(%+*Z`#-1#F.&$=,`%)[!,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@#%],NU^TD70PJ'-BI>_`.5$>*^@%9@CP>*BO@"]3` M`5`$=D,OWDC\I0!TP#^R!^#0YP&#JX$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;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\=@$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^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[ID" 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$%$+<&*9>Q"$[9`)$G329( MZ3D7['\L@DQH`E,`!$B!.N`&6@`52`-MH`R``":0!L2`'`@#PW7X#N=A0=R' MX;`!-X"*-?$<&,9C0!RG@53\BZTP'9#&8^`-M($V$`9.,0A@`[RX#+`` MQ5L&P@`96,C2^!R?@4QD<$Y>Q2``%==C:NP&A/!' M%L+9^!R;XDV,A,-`$*['>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@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@;=FONQP-`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: 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: 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 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: 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" 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: 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 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: 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 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: 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 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: 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 Message-Id: <9203311627.AA24957@SOS> To: Chuck Boyer 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 /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: 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 , 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: 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 > /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: 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 , 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: 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: 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 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: 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: 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 ; 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 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: 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: 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: 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. <...!mcsun!ukc!robots.oxford.ac.uk!jon> From linux-standards-request@banjo.concert.net Tue Mar 31 22:27:50 1992 Return-Path: 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" 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: 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: 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 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: 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: 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: 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 , 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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: 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 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: 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 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: 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 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: 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 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: 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 > 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: 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 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: 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: 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 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: 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: 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 ); 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 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: 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 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: 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: 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 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: 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 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: 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: 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: 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: 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: 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: 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 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: 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 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: 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 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: 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: 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: 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 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: 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 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: 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: 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 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: 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: 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| 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: 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 ; 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 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: 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: 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 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 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 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 Suppose one "not friendly" user want to give me trouble .... Very easy, malloc (BIGNUM); for (x=0;x 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 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: 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 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: 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: 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: 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 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: 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 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: 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 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 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: 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 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: 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 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 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: 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." To: Adam Thompson 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.